devel

devel@lists.centos.org

4 participants
4640 discussions

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

Qemu VS GlusterFS - liburing rpm conlisions
by lejeczek 29 Jun '23

29 Jun '23

Hi guys. Just to let you know that with GlusterFS & latest qemu updates - on Centos 9 I'd image most will have these - there are conflicts which brake update: -> $ dnf update Error: Problem 1: package qemu-img-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1()(64bit), but none of the providers can be installed - package qemu-img-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1(LIBURING_0.1)(64bit), but none of the providers can be installed - package qemu-img-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1(LIBURING_0.2)(64bit), but none of the providers can be installed - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from @System - cannot install the best update candidate for package qemu-img-17:8.0.0-2.el9.x86_64 - cannot install the best update candidate for package liburing-2.0-1.el9s.x86_64 Problem 2: package glusterfs-server-11.0-1.el9s.x86_64 from @System requires liburing.so.2()(64bit), but none of the providers can be installed - package glusterfs-server-11.0-1.el9s.x86_64 from @System requires liburing.so.2(LIBURING_2.0)(64bit), but none of the providers can be installed - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from @System - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from centos-gluster11 - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from centos-gluster11-test - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1()(64bit), but none of the providers can be installed - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1(LIBURING_0.1)(64bit), but none of the providers can be installed - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1(LIBURING_0.2)(64bit), but none of the providers can be installed - cannot install the best update candidate for package qemu-kvm-core-17:8.0.0-2.el9.x86_64 - cannot install the best update candidate for package glusterfs-server-11.0-1.el9s.x86_64 Problem 3: problem with installed package liburing-2.0-1.el9s.x86_64 - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from @System - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from centos-gluster11 - cannot install both liburing-0.7-7.el9.x86_64 from appstream and liburing-2.0-1.el9s.x86_64 from centos-gluster11-test - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1()(64bit), but none of the providers can be installed - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1(LIBURING_0.1)(64bit), but none of the providers can be installed - package qemu-kvm-core-17:8.0.0-4.el9.x86_64 from appstream requires liburing.so.1(LIBURING_0.2)(64bit), but none of the providers can be installed - problem with installed package qemu-kvm-core-17:8.0.0-2.el9.x86_64 - package qemu-kvm-core-17:8.0.0-2.el9.x86_64 from @System requires qemu-kvm-common = 17:8.0.0-2.el9, but none of the providers can be installed - package qemu-kvm-core-17:8.0.0-2.el9.x86_64 from appstream requires qemu-kvm-common = 17:8.0.0-2.el9, but none of the providers can be installed - cannot install both qemu-kvm-common-17:8.0.0-4.el9.x86_64 from appstream and qemu-kvm-common-17:8.0.0-2.el9.x86_64 from @System - cannot install both qemu-kvm-common-17:8.0.0-4.el9.x86_64 from appstream and qemu-kvm-common-17:8.0.0-2.el9.x86_64 from appstream - cannot install the best update candidate for package qemu-kvm-common-17:8.0.0-2.el9.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) many thanks, L.

4 13

Where can I find updated CentOS artwork?
by Gordon Messmer 29 Jun '23

29 Jun '23

I don't want to reopen https://git.centos.org/centos/Artwork/issue/1 , but I'm not sure where to ask questions about the status of that work. The centos.org sites (www., wiki., and git.) use updated logos, but I can't find any updated artwork described at https://wiki.centos.org/ArtWork or any linked page. It's possible that I'm overlooking it. Any pointers?

4 4

ISA SIG rebuild status
by Florian Weimer 28 Jun '23

28 Jun '23

Last week, the ISA SIG concluded two rebuilds of a snapshot of CentOS 9 Stream with GCC 12, one with -march=x86-64-v2 (same as CentOS 9 Stream), and one with -march=x86-64-v3. The rebuilds are fairly complete. The following things are missing: * All modular content. * LibreOffice and OpenJDK. * Two Rust packages which require a rebase of their bundled rust-bindgen versions for Clang 16 compatibility. (Rust currently does not follow the subarchitecture in CFLAGS anyway.) I classifed most of the initial build failures, and here are some numbers: GCC 12 induced failures GCC 12 exposes latent undefined behavior 2 various issues (mostly -Werror) 18 GCC 12 C++ header inclusion changes 3 subtotal 23 x86-64-v3 test differences 7 general buildroot/time/policy changes 19 grand total 49 (We switch to GCC 12 for auto-vectorization at -O2 using the very-cheap cost model, something that cannot be model with GCC 11 compiler flags. Without that, a forward-looking comparison between -march=x86-64-v2 and -march=x86-64-v3 is not possible.) The x86-64-v3 test differences are mostly due to GCC's -ffp-contract=fast default, which does not match what some package test suites expect. We saw those on other architectures already, and with -march=x86-64-v3, GCC supports FMA, exposing them for the x86_64 architecture as well. Maybe upstream GCC can revisit the default there. The general failures are in some cases literally due to time because test certificates expired, or a hard-coded date in some test is no longer in the future. Disabling SHA-1 broke some tests as well. The rest is just general drift of build dependencies, introducing incompatibilities. FTBFS bugs have been filed in Red Hat Bugzilla as appropriate. We were able to eliminate a bunch of rebuild issues that are specific to the CBS Koji environment and do not show up in other environments. I should probably send out a separate note about that, in case other SIGs want to do mass rebuilds. We are still working out how to best deliver the rebuilt packages for testing. Until then, the packages are available from the Koji buildroot and can be (mostly) installed with “dnf distro-sync” from an existing CentOS 9 Stream system: <https://cbs.centos.org/kojifiles/repos/isa9s-packages-baseline-el9sbase-bui…> <https://cbs.centos.org/kojifiles/repos/isa9s-packages-optimized-el9sopt-bui…> I would like to thank Troy Dawson for shepherding the build process and reviewing and fixing issues, and Brian Stinson for resolving CBS Koji infrastructure issues. Florian

4 5

9-stream repo file for centos-plus(containing thunderbird)?
by Anthony Alba 27 Jun '23

27 Jun '23

Hi list, Which repo file contains the metalink to centos-plus(containing thunderbird). Here is my current list of repo files but none seem to reference centos-plus. Cheers AA # current list of repo files etc/yum.repos.d/centos-addons.repo etc/yum.repos.d/CentOS-Ceph-Pacific.repo etc/yum.repos.d/CentOS-Ceph-Quincy.repo etc/yum.repos.d/CentOS-Gluster-10.repo etc/yum.repos.d/CentOS-Gluster-11.repo etc/yum.repos.d/CentOS-Gluster-9.repo etc/yum.repos.d/centos-kmods.repo etc/yum.repos.d/centos-kmods-userspace.repo etc/yum.repos.d/CentOS-Messaging-rabbitmq.repo etc/yum.repos.d/CentOS-NFS-Ganesha-4.repo etc/yum.repos.d/CentOS-NFS-Ganesha-5.repo etc/yum.repos.d/CentOS-NFV-OpenvSwitch.repo etc/yum.repos.d/CentOS-OKD-4.13.repo etc/yum.repos.d/CentOS-OKD-4.14.repo etc/yum.repos.d/CentOS-OpenStack-antelope.repo etc/yum.repos.d/CentOS-OpenStack-Client-xena.repo etc/yum.repos.d/CentOS-OpenStack-yoga.repo etc/yum.repos.d/CentOS-OpenStack-zed.repo etc/yum.repos.d/CentOS-OpsTools.repo etc/yum.repos.d/CentOS-oVirt-4.5.repo etc/yum.repos.d/CentOS-oVirt-4.5-testing.repo etc/yum.repos.d/centos.repo etc/yum.repos.d/CentOS-Samba-414.repo etc/yum.repos.d/CentOS-Samba-415.repo etc/yum.repos.d/CentOS-Samba-416.repo etc/yum.repos.d/CentOS-Samba-417.repo etc/yum.repos.d/CentOS-Samba-418.repo etc/yum.repos.d/CentOS-Storage-common.repo etc/yum.repos.d/CentOS-Stream-Hyperscale-Experimental.repo etc/yum.repos.d/CentOS-Stream-Hyperscale.repo etc/yum.repos.d/CentOS-Stream-Hyperscale-Spin.repo etc/yum.repos.d/epel-next.repo etc/yum.repos.d/epel-next-testing.repo etc/yum.repos.d/epel.repo etc/yum.repos.d/epel-testing.repo

2 2

Furthering the evolution of CentOS Stream
by Leon Fauster 26 Jun '23

26 Jun '23

Hi All, I wonder if someone is in the role/position to shed some more light on the topic as announced here https://www.redhat.com/en/blog/furthering-evolution-centos-stream Any deadlines? Does this target only EL10 or also any current release? Would be great if some discussion/communication could be happen. Thanks! -- Leon

7 20

How was the old centos git repo maintained?
by Gordon Messmer 22 Jun '23

22 Jun '23

I never paid much attention to the repos in the past, but after reading a comment about "exploded src.rpms" I picked one to review... (https://git.centos.org/rpms/bash/commits/c8) It looks like there was a process (or a person?) that would unpack released src.rpms into a git repo, delete Source0, and then commit whatever was left. Is that approximately correct?

2 1

2023-06-14 - CentOS Public Board Meeting
by Thomas Oulevey 13 Jun '23

13 Jun '23

Hi Everyone, Our next board meeting will take place at 20:00 UTC tomorrow: `date -d "2023-06-14 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/ry93GGRI2 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

Planned Outage - networking upgrades - 2023-06-13 20:00 UTC
by Fabian Arrotin 13 Jun '23

13 Jun '23

Forwarding here the info that was sent to Fedora infra list ( https://pagure.io /fedora-infrastructure/issue/11365 ) In summary, today you'll probably see some services being unreachable, and impacted services are the ones located in the Fedora DC (it doesn't impact https://cbs.centos.org and others). Impacted services: - https://accounts.centos.org (and https://fasjson.fedoraproject.org that some infra services are using to retrieve users info and groups) - ns2.centos.org Worth knowing that, due to network upgrade, we'll also have to power off in advance some Virtual Machines that are located on a remote iscsi block device. And at the same time we'll also convert some VMs/KVM hosts from centos 7 to el9 Kind Regards, -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

1 0

Discussion: Open technical questions concerning SIG content for RHEL releases
by Peter Georg 09 Jun '23

09 Jun '23

Dear all, There has been an inquiry to the CentOS Board to clarify how long SIGs can expect to be able to build against RHEL build targets [1]. This is necessary to allow SIGs themselves to communicate expected lifecycle of their content to users. The outcome of this, in summary, is that SIGs should be able to build against RHEL until it reaches EOL (end of Maintenance Phase) + 30 days (no access to ELS content). This policy follows the one used by EPEL. Note: It is (obviously) still up to every single SIG to decide if and for how long they want to support a particular RHEL (or CentOS Stream) release. This inquiry also included respectively raised some technical questions. These technical questions are not to be decided by the CentOS Board. In [2] it has been recommended to discuss these on centos-devel. So let's do that. I want to start with two open questions which I do know of. In case there are other open question concerning this matter please raise them here. First open question is where to push content produced by SIGs for RHEL8 to. To better understand the issue, let me summarize the current situation, for which we first need to define the used format for tags in CBS: <sig><el>-<project>-<version>-{candidate,testing,release} where <el> can currently be 7,8,8s,9,9s Packages tagged for -testing are pushed to: https://buildlogs.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/ Packages tagged for -released are push to: If el = 8 or 8s: debuginfo rpm packages: https://debuginfo.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/ src.rpm packages: https://vault.centos.org/centos/<el>/<sig>/Source/<project>-<version>/ Everything else: http://mirror.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/ If el = 9 or 9s: http://mirror.stream.centos.org/SIGs/<el>/<sig>/<arch>/<project>-<version>/ For src.rpm <arch> is source. Note: Although it is not relevant for the discussion, in fact on the mirrors the suffix "s" of <el> is replaced by "-stream". This currently is all fine. However it is planned that the infrastructure currently used for packages built for 8 or 8s will disappear once CentOS Stream 8 and CentOS Linux 7 are EOL (June 30th, 2024). So in case any SIG decides to produce content for RHEL 8 after that date packages can not be distributed properly anymore. Only using the -testing tag and thus https://buildlogs.centos.org is not really an option as it would probably produce too much load on these. My proposal: After CentOS Stream 8 went EOL (May 31st, 2024), which is the same date as the end of the Full support phase of RHEL 8, at least the -release tag of all RHEL 8 build targets is locked and SIGs have to opt-in in case they want to build content for RHEL 8 during its Maintenance Support phase (End: May 31st 2029) for a particular build target. For these, tagging for -release will then push content to http://mirror.stream.centos.org/SIGs/8/<sig>/<arch>/<project>-<version>/, i.e. the same location as used for 9 and 9s. This gives SIGs one month for all required changes before the currently infrastructure disappears. Of course this means additional work for SIGs and Infra. However at some point the location where to push content to has to be changed before the currently used infrastructure disappears. Choosing an earlier date would result in work for SIGs who do not want to continue providing any packages once RHEL 8 enters Maintenance Support phase anyway. The second open question concerns the centos-release-* packages provided by SIGs to allow users to easily consume SIGs' content. For 8s and 9s the CBS tags extras<el>-extras-common-{candidate,testing,release} are used to build these packages. This repository is added in CentOS Stream 8 and 9. For packages build for RHEL 8 and 9 there is currently no common way to provide any means of easing the process to consume SIGs' content. My proposal to fix this is by adding extras<el>-extras-common-{candidate,testing,release} for <el> = 8 and 9, i.e., using the same system as currently used for 8s and 9s. To further ease the process I propose to introduce a package named centos-release-extras which contains the repository config pointing to the content of the tags extras<el>-extras-common-{testing,release} (only -release enabled by default) and the CentOS-SIG-Extras GPG key. The centos-release-extras packages itself would be built in the extras<el>-extras-common-el<el> build target. Users of RHEL would then only need to install this single package to allow them to easily install any other centos-release-* packages. Obviously someone needs to maintain the centos-release-extras package. I volunteer to maintain this package. [1]: https://git.centos.org/centos/board/issue/82 [2]: https://pagure.io/centos-infra/issue/1002

4 11

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