devel

devel@lists.centos.org

4 participants
4639 discussions

[Storage SIG] Problems installing ceph + qemu-kvm in C9S
by Alfredo Moralejo Alonso 12 Jul '23

12 Jul '23

Hi, After the update of liburing in centos stream 9, we are having issues to install ceph and qemu-kvm together: # dnf install ceph qemu-kvm Last metadata expiration check: 0:01:00 ago on Mon Jul 10 14:02:55 2023. Error: Problem: cannot install both liburing-2.3-2.el9.x86_64 and liburing-0.7-7.el9.x86_64 - package qemu-kvm-core-17:8.0.0-6.el9.x86_64 requires liburing.so.2()(64bit), but none of the providers can be installed - package qemu-kvm-core-17:8.0.0-6.el9.x86_64 requires liburing.so.2(LIBURING_2.0)(64bit), but none of the providers can be installed - package ceph-osd-2:17.2.3-2.el9s.x86_64 requires liburing.so.1()(64bit), but none of the providers can be installed - package ceph-osd-2:17.2.3-2.el9s.x86_64 requires liburing.so.1(LIBURING_0.1)(64bit), but none of the providers can be installed - package qemu-kvm-17:8.0.0-6.el9.x86_64 requires qemu-kvm-core = 17:8.0.0-6.el9, but none of the providers can be installed - package ceph-2:17.2.3-2.el9s.x86_64 requires ceph-osd = 2:17.2.3-2.el9s, but none of the providers can be installed - cannot install the best candidate for the job Any help from storage sig will be appreciated. Best regards, Alfredo

4 4

Making the redhat selinux-policy repository publicly available
by Daan De Meyer 11 Jul '23

11 Jul '23

Hi, It seems that the selinux-policy rpm is built from git@gitlab.cee.redhat.com:SELinux/selinux-policy.git which seems to be a redhat internal repository. More specifically, if I try to checkout the commit listed in the selinux-policy spec (https://gitlab.com/redhat/centos-stream/rpms/selinux-policy/-/blob/c9s/seli…) in the fedora-selinux repository cloned from github, I get an error saying that the commit does not exist. It would be great if the repository containing this commit was publicly available and open for external contributors just like all the other packages in CentOS Stream. Is it possible to make this happen? Cheers, Daan De Meyer

3 3

2023-07-12 - CentOS Public Board Meeting
by Thomas Oulevey 10 Jul '23

10 Jul '23

Hi Everyone, Our next board meeting will take place at 20:00 UTC on Wednesday: `date -d "2023-07-12 20:00 UTC"` If you would like to attend please send me an email to alphacc(a)centosproject.org ( please do not reply to @centos-devel or use another email address) and you will receive a link to a Zoom meeting room with a passcode, 1 hour before the meeting takes place. The agenda can be checked at (work in progress) : https://hackmd.io/@centosboard/HyP-UuFt2 As a reminder we will enforce few rules : * Wait to be recognized by the Chair before speaking * Respect the Chair when told your time to speak is over - this will allow us to remain on agenda, and complete the meetings in the allotted time * In the event that there are Board-confidential topics, these will be put at the end of the meeting, in Executive Session, and guests will be asked to leave. We hope to minimize these items, but they do sometimes happen. The most common scenarios in which this may happen are personnel issues, or information that Red Hat wishes to share with the Board, but is not yet public. * Muting of participants, or, in extreme situations, ejection from the meeting, is at the sole discretion of the Chair. * Meetings will be recorded, and published to YouTube (possibly with edits/redaction, as approved by the Directors). Thus, by joining the meeting you consent to have your presence at the meeting, and anything you say during the meeting, made public. I hope some of you can join. Sorry for the late announcement. thanks, -- Thomas 'alphacc' Oulevey CentOS Board of Directors Secretary alphacc(a)centosproject.org

1 0

Help with reproducing tests locally
by Carlos Rodriguez-Fernandez 08 Jul '23

08 Jul '23

Hi All, I've been trying to reproduce the centos tests locally. Thank to Aleksandra and arrfab for the help on IRC to understand the whole process conceptually. I successfully ran https://github.com/CentOS/sig-core-t_functional on a clean centos stream 9 vm. The tests passed. I'm running into issues trying to run individual playbooks against a clean centos stream 9 vm from the zuul-jobs and jobs repositories from here: https://gitlab.com/redhat/centos-stream/ci-cd/zuul The errors I find are mainly related to dependencies, e.g., missing users, or packages, which makes me think there are steps I need to do before. Is there any documentation for contributors about the zuul CI tests, to be able to test individual playbooks locally? If there is none, I could contribute with some in a Readme.md, but I would still need some basic guidance to get at least some of them working locally. Any help is appreciated. Regards, Carlos.

1 1

[ISA SIG] Meeting notes 2023-07-07
by Florian Weimer 07 Jul '23

07 Jul '23

We met for the first time today. Florian briefly summarized the status of the CentOS 9 Stream rebuilds with x86-64-v2 and x86-64-v3. For details, please see: [CentOS-devel] ISA SIG rebuild status <https://lists.centos.org/pipermail/centos-devel/2023-June/143007.html> Since then, Troy has added consumption documentation describing how to consume the builds: Convert CentOS Stream 9 to ISA <https://sigs.centos.org/isa/consuming/centosstream9/#convert-centos-stream-…> Currently, there are no plans to keep the package set up-to-date with regards to CentOS 9 Stream. Troy plans to create centos-release-isa package which, upon installation, creates the unusual repository configuration. This will be an explicit download, not part of CentOS Extras, out of concern that people might try to install it accidentally otherwise. Ali raised the matter of zlib-ng (see the previous mailing list thread). Florian thinks that zlib-ng in compat mode is something to explore. This work should happen in Fedora first, targeting Fedora 40. Florian to send email to relevant parties. Troy and Florian are going to explore creating two container images for each rebuild variant, so that people have a more familiar starting point for some quick experiments. We plan to reconvene on July 21st, at 16:00 UTC (date and time still tentative; it's the alternate slot for the bi-weekly Fedora ELN meeting). Please drop me a line if you want to be added to the meeting invitation. Update of the CentOS calendar is still pending: <https://github.com/CentOS/Calendar/pull/62> (We will likely keep using Google Meet instead of IRC, though.) Thanks, Florian

1 0

[Storage-SIG] cephadm package is old
by Luis Domingues 07 Jul '23

07 Jul '23

Hi. During an installation, I saw that almost all ceph packages for ceph pacific are in the last version, v16.2.13 except for cephadm. The last version is v16.2.7. Is any reason for that? Or is it just a mistake? Thanks Luis Domingues Proton AG

2 1

Build for main CentOS Stream repos with subpackages in a SIG repo
by Sandro Bonazzola 04 Jul '23

04 Jul '23

Hi, is it possible to have a build from https://kojihub.stream.centos.org/koji/ having subpackages that are not going to be shipped in main CentOS Stream repos being somehow filtered to ship those subpackages into a SIG repo? I'm asking specifically about qemu-kvm sub packages we'd like to have in CentOS AutoSD SIG but that are not going to be shipped in main CentOS Stream repos as not relevant/supported in RHEL (qemu-kvm-ui-dbus, BZ# *2207940* <https://bugzilla.redhat.com/show_bug.cgi?id=2207940>). I would like to avoid having to rebuild the same qemu-kvm build within the SIG each time a new release lands in CentOS Stream just to get a subpackage. Is this possible? Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING - Red Hat In-Vehicle Operating System Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

2 1

t_functional tests :: github checks broken, and the fix.
by Carlos Rodriguez-Fernandez 03 Jul '23

03 Jul '23

Hi Fabian Arrotin, I submitted a PR with a set of tests for libbpf-tools: https://github.com/CentOS/sig-core-t_functional/pull/88 The PR is failing because the python package duffy does not work with pydantic >= 2.0. I provided a commit in my PR that fixes that issue by pinpointing the version to the latest pydantic 1.x version (1.10.10 from 2023-06-30). That commit may need to be cherry picked first to then see if my PR passes the checks. Thank you, Carlos.

1 0

Scheduling the CentOS ISA SIG meeting
by Florian Weimer 30 Jun '23

30 Jun '23

I'd like to propose bi-weekly meetings for the ISA SIG. What about reusing the slot of the Fedora ELN SIG in alternating weeks? The first meeting would then be Friday, July 7th, 16:00 UTC. I proposed that here: Schedule initial sequence of ISA SIG meetings <https://github.com/CentOS/Calendar/pull/62> I'm aware of the holidays in Czechia and the United States next week, but it's just the first meeting, with more to follow. If that slot doesn't work in general and you want to participate in the meetings, please let me know (off-list if you prefer). Thanks, Florian

1 0

Adding bootc images - part of Cloud SIG or separate?
by Colin Walters 29 Jun '23

29 Jun '23

Hello, I'm a developer on Fedora/RHEL and OpenShift. Lately we've been landing a lot of "bootable container" changes in OpenShift core, and there's a lot more to come. However, as we've been doing about this...I've been saying to people that I wish I had a time machine to go back and do bootable containers from the start. There's a lot of things we're doing today that I think we should stop doing, e.g.: - Switching to kernel-rt by fiddling with each node; we should be simply pulling a pre-built bootable container image with that kernel (more on this below) - Getting away from injecting so much persistent state by default (both via Ignition and outside of it) And crucially, I think we should be developing tools and techniques that apply *outside* of Kubernetes/OpenShift and also work well with it. To be direct, I'd like to eventually productize some of what's happening here in RHEL, not in OpenShift. As part of this (potential) re-architecture of how we think of systems management, I created the https://github.com/containers/bootc project. To be direct: If successful, I think bootc will be the successor to (rpm-)ostree. It's also intended to much more closely align with the github.com/containers organization. A simple way to think of this is: One can (build and) run *application* containers with podman; and these containers can also be run in e.g. Kubernetes/OpenShift. One can build *bootable* containers using any tooling (including podman build), but *running* them is via bootc on the end machine. bootc understands kernels etc. But there's a lot to figure out here - and I want to have a space to figure out this stuff and experiment with it outside of a direct-to-product path. I think a CentOS SIG makes sense for this. So what I'd like to do is either: - Add a new effort to the Cloud SIG, which currently (IMO a bit confusingly) hosts OpenStack/RDO and OpenShift/OKD things which would be a 3rd thing. The bootc work would then be the "base OS" split for OKD/SCOS. But of course, nothing stops one from building bootable host images that are instead designed to be RDO/OpenStack hosts. - Or, create a new SIG Personally, I lean towards the latter because honestly I find the naming "Cloud" to be misleading - bootc is also intended to be useful for standalone, non-cloud-infrastructure settings (such as desktops and IoT). Specifically, I'd like to transfer the existing code that lives in https://github.com/cgwalters/bootc-demo-base-images (specifically https://github.com/cgwalters/bootc-demo-base-images/blob/main/c9s.yaml ) into something CentOS-affiliated and explicitly maintained by a team. (Though I'm not super excited to move it to pagure like at least some other SIG content, but let's not get distracted by git hosting too much here). Another way to say it is that I'd love to ship quay.io/centos/centos-boot:stream9 (notice the -boot). Or failing that, it'd be quay.io/centos-boot/centos-boot:stream9 or so. There's a *lot* to discuss in terms of what actually goes in these base images, and also ensuring it's equally ergonomic for users to build their own base images. So really it's very likely there wouldn't be just *one* base image. In fact, I recently introduced a -rt variant with the RT kernel: https://github.com/cgwalters/bootc-demo-base-images/commit/68afb072a5a1396c… - and this was specifically motivated by issues we hit in OCP. But again, I want to have a space where we try to do more of a "clean(er) slate" approach for a while, with notes "not for production use" - for a while. Everything done here though *is* made with that as an explicit goal though (e.g. it's a toplevel design goal too that existing ostree-based systems can be seamlessly switched to be container-based without reprovisioning). At the same time, bootc already introduces some quite new things that need design iteration; for example: https://github.com/containers/bootc#using-bootc-install - we ship tooling such that a container can install itself (without going through a raw disk image as is used by both OCP and Edge deployments today). And at the same time, I'd like to aim to get the Anaconda changes to install these bootable containers in https://github.com/rhinstaller/anaconda/pull/4561 OK this is already too long, so I'm just going to click send =) Thoughts?

7 10

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel