devel

devel@lists.centos.org

2 participants
4695 discussions

2024-11-13 - CentOS Public Board Meeting
by Thomas Oulevey 07 Nov '24

07 Nov '24

Hi Everyone, Our next board meeting will take place at 21:00 UTC next Wednesday `date -d "2024-11-13 21: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 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/SJDtP3cZJe 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. thanks, -- Thomas 'alphacc' Oulevey CentOS Board of Directors Secretary alphacc(a)centosproject.org

1 0

[FYI] : all CBS koji builders now reinstalled on el9
by Fabian Arrotin 05 Nov '24

05 Nov '24

Sending this ticket for awareness : In the last days, I had time to disable some koji builders (https://cbs.centos.org/koji/hosts) , reinstall/migrate these from el8 to el9, and enable these builders back in the available pool. It finished today [1] and so all builders, all architectures are now running el9.4 . Only the kojihub infra is still running on el8 but that will be migrated later (kojihub itself doesn't have any impact on build infrastructure). The main reason why we updated was to ensure we'd be running a newer kernel for the systemd-nspawn isolation, that was causing troubles when running on top of el8 (kernel 4.18) , especially when relying on likcapi calls from within the chroot'ed build env. For more details and workaround (not needed anymore) that we used to allow building CentOS Stream 10 pkgs for SIGs, see [2] At the same time, what triggered also the reinstall was also the need to re-balance workload across different hardware/chassis [3] : the x86_64 kojid builders are in fact running on some un-warrantied (and older) machines and I wanted to reconfigure similar machines dedicated previously for some other things (including CI / on-premises openshift cluster / etc) to ensure that we'd still have some x86_64 builders running behind https://cbs.centos.org, should we encounter a whole chassis hardware failure . Same for some small services used by koji builders themselves (like small cache/proxy to retrieve external content, like gitlab.com - now spread across two distinct hardware with ucarp and floating ip address[es] for ha purposes) You'll see that we have now more x86_64 builders, and that some tasks (like createrepo, rebuildSRPM, etc) are exclusively targeted on these hosts, freeing some cpu cycles from aarch64/ppc64le/s390x builders, that will be only used for specific rpmbuild tasks. Also worth knowing that I was able (due to decommissioned cores/memory that was used for centos stream 8/centos linux 7) to extend/tune number of cores/available memory on reinstalled aarch64 and ppc64le koji builders, hopefully helping to build faster your SIGs packages for these architectures. Nothing is required from you, SIGs builders, as the whole migration happened transparently , without any downtime, so just enjoy more compute capacity / redundancy for https://cbs.centos.org (and let's hope that we'll not suffer from hardware failure in the future) [1] https://pagure.io/centos-infra/issue/1505 [2] https://pagure.io/centos-infra/issue/1474 [3] https://pagure.io/centos-infra/issue/1528 -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

1 0

Board Nominations Requested
by Shaun McCance 04 Nov '24

04 Nov '24

** Please read this entire email before responding with nominations. ** We have a process, and the process is important. Recently, Brian Exelbierd notified the CentOS board that he will be moving on from his role as Red Hat Liaison. The Red Hat Liaison role is special: it is the only board seat appointed by and speaking for Red Hat. All other board members are at-large and speak for themselves. Brian's role will be backfilled, but until it is, Josh Boyer will step in as the interim Red Hat Liaison. This means that Josh is stepping down from his position as an at-large board member. See Brian's and Josh's emails for more info: https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/QAG4… https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/BCWM… We are asking you, the CentOS community, for nominations for who should fill Josh's seat. Note that the vote on who will fill this seat is held by the board itself, but nominations are open to the entire community. If you would like to nominate someone (or self-nominate), please use this Google form: https://forms.gle/jqYF7v5AUVy6L1Fz6 Please DO NOT send nominations to this list. As this is not a public vote, we don't want to give the impression of a popularity contest with public nominations. We also want to avoid any shaming if someone is nominated and is not seated, or chooses not to accept. I will ensure that each nominee is willing and able to serve, and the board will consider them and select the next director from the list. If you wish to nominate someone, you should consider the list of director requirements and recommendations listed at: https://www.centos.org/about/governance/director-requirements/ Nominations will be open until September 23. Thank you for your thoughtful consideration and participation in this process. -- Shaun, for the CentOS Board of Directors

2 2

CentOS Showcase starting in a few hours
by Troy Dawson 04 Nov '24

04 Nov '24

Don't miss our first CentOS Showcase. https://pretix.eu/centos/showcase-2024-11/ What is it? Just what it sounds like. Various people will be showcasing the awesome the work happening in, and with, the CentOS ecosystem. Schedule: https://cfp.fedoraproject.org/centos-showcase-2024-11/talk/ See you there! Troy

1 0

Introducing Community Linux Engineering (“CLE”)
by Brendan Conoboy 21 Oct '24

21 Oct '24

Hi everybody, The “CPE” name is a commonly used identifier in the Fedora and CentOS communities. Inside Red Hat, it meant a specific set of individuals and roles reporting into common management. We recently had a reorg that brought it and other community roles together. There is a new name for the whole group: Community Linux Engineering. To be clear, no one is changing roles as part of this; all the things Red Hatters did before the reorg and rename remain the same after. This change does bring a question with it: In our docs and conversations, should we just search and replace the CPE name with “CLE”? My answer is a resounding no! The external CPE branding unintentionally contributed to some common misconceptions: - “Red Hat teams are separate from the community.” Red Hatters can, and indeed many do, play key roles in the community Linux space, regardless of team affiliation. - “Community members can’t take part in the same Fedora activities that Red Hat employees can.” The reality is that most activities are or can be open to all. - “There is a ‘Fedora team’ or a ‘CentOS team’ solely responsible for All the Things.” This would be impossible – it’s way too much. We all are part of making these distributions and communities succeed and grow. As this name change takes effect, I hope we can embrace names which reflect what we are doing together, the myriad skills and interests and activities that come together to make something we can all use and enjoy. So while I’m pleased to announce CLE, I hope you’ll promptly forget about the name and instead focus on why you’re here in this community, and find yourself able to pursue your interests as we build amazing things together.

1 0

CentOS Stream 10 availability for CI tenants (aka duffy.ci.centos.org)
by Fabian Arrotin 21 Oct '24

21 Oct '24

As discussed back and forth with CI tenants using duffy.ci.centos.org (see https://sigs.centos.org/guide/ci/#duffy-ephemeral-bare-metalvirtual-machine…) , there was a request to start testing against/for Stream 10 (as it was available already for SIGs building against/for it on https://cbs.centos.org) I had time to work on this ticket (https://pagure.io/centos-infra/issue/1519) so I'm happy to share that you can now request through same duffy api calls CentOS Stream 10 machines that you'll be able to use for your CI tests. Please just keep in mind that Stream 10 packages set is still subject to major changes, but at least this gives you an opportunity to test things in advance. Happy testing ! -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

1 0

CentOS Showcase CFP Reminder
by Shaun McCance 17 Oct '24

17 Oct '24

Hi all, As a reminder, we'll be hosting a CentOS Showcase on November 4. This is a half-day virtual event with short talks that showcase the work being done around the project. The CFP is open until this coming Monday, October 21. https://cfp.fedoraproject.org/centos-showcase-2024-11/ Please submit talks about the work you're doing. We'd especially like to hear updates from our SIGs. Remember that these are short talks, just 20 minutes, so there's no need to prepare a technical deep dive. Also, if you haven't already, please register to attend: https://pretix.eu/centos/showcase-2024-11/ Thanks, Shaun

1 0

installing packages after CentOS Stream 9 EOL
by Ken Dreyer 17 Oct '24

17 Oct '24

Hi folks. We use CentOS Stream for Ceph's CI along with other distributions. When CentOS Stream 8 went EOL, we could no longer "yum install" packages for it. As a result, Ceph's build and testing infrastructure broke in important ways that were difficult to debug. Engineers spent a lot of unplanned time fixing things. For example, in Ceph we test many upgrade paths against very old versions, because we want confidence in our upgrade processes. Several of these old environments are EOL, but these tests are important to our users. When Ceph upgrades are stable, our users have confidence to get onto non-EOL releases. The security risk of using EOL bits in our test lab is acceptable because our environment is a secured network where we reimage regularly. The Ceph project was not alone with broken CI recently. Other projects that experienced similar trouble when we could not install packages on EOL CentOS. When I "podman pull ubuntu:trusty", I can "apt update" and still install packages. That went EOL in 2019. When I "podman pull" end-of-life fedoras, like fedora:31, I can "dnf install" packages too. When CentOS Stream 9 goes EOL, would you please update MirrorManager so that package installs continue to work?

3 2

RDO Dalmatian 2024.2 Released
by Amy Marrich 15 Oct '24

15 Oct '24

The RDO community is pleased to announce the general availability of the RDO build for OpenStack 2024.2 Dalmatian for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Dalmatian is the 30th release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available for CentOS Stream 9 on the CentOS mirror network in: http://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-dalmat… The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Stream and is a member of the CentOS Cloud SIG. The Cloud SIG focuses on delivering a great user experience for CentOS users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. The highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/dalmatian/highlights.html but here are some highlights: - New Cinder driver features were added, notably, Dell PowerStore active-active support, Dell PowerStore QoS support, NetApp added support to active/active mode in ISCSI/FC drivers, HPE Nimble replication, and StorPool added support clone-across-pools capability. - Added Glance support of new add/get location APIs which replaces the image-update (old location-add) mechanism for consumers like cinder and nova to address OSSN-0090 and OSSN-0065. - Ironic has enhanced multiple security aspects, for example it now requires rescue passwords to be hashed, it has reduced the logged nodes information during the cleaning phase to avoid showing sensitive data, and it has hardened the communication between the ironic services and the ironic agent requiring an HTTPS url by default. - All Neutron supported mechanism drivers (ML2/OVS, ML2/OVN) can now use the WSGI API module, completing the first phase of eventlet library deprecation. - Nova Instances with UEFI firmware can now be launched with stateless firmware if their image has the hw_firmware_statelessproperty and if the compute services have libvirt 8.6.0 or later. OpenStack Dalmatian is not marked as Skip Level Upgrade Release Process or SLURP. According to this model ( https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad…) this means that upgrades will only be supported from the Caracal 2024.1 release. RDO Dalmatian 2024.2 has been built and tested with the recently released Ceph 18.2.0 Reef version (https://docs.ceph.com/en/latest/releases/reef/) which has been published by the CentOS Storage SIG in the official CentOS repositories. *Note:* Follow the instructions in [RDO documentation]( https://www.rdoproject.org/install/install-with-ceph/) to install OpenStack and Ceph services in the same host. During the Dalmatian cycle, some projects have been retired or declared inactive upstream. As such, the following packages for some projects are not present in the RDO Dalmatian 2024.2 release: - python-saharaclient (https://review.rdoproject.org/r/c/rdoinfo/+/54360) - puppet-corosync (https://review.rdoproject.org/r/c/rdoinfo/+/53127) During the next release we will continue working on retiring inactive packages in order to ensure RDO content quality and security. Contributors: During the Dalmatian cycle, we saw the following new RDO contributors: - Roman Safronov - Archana Singh - pkomarov komarov - Sergii Golovatiuk - Milana Levy - Liron Kuchlani - Jaromír Wysoglad - Arnau Verdaguer - Andre Aranha Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 51 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and rdo-website repositories: - Alfredo Moralejo Alonso - Amy Marrich - Ananya Banerjee - Andre Aranha - Archana Singh - Arnau Verdaguer - Artom Lifshitz - Arx Cruz - Bhagyashri Shewale - Bohdan Dobrelia - Cédric Jeanneret - Chandan Kumar - Daniel Pawlik - Douglas Viroel - Fabien Boucher - Fiorella Yanac - Francesco Pantano - Goutham Pacha Ravi - Gregory Thiemonge - Grzegorz Grasza - Harald Jensås - Jaromír Wysoglad - Joan Francesc Gilabert - Joel Capitao - Jon Schlueter - Karolina Kula - Karthik Sundaravel - Lewis Denny - Liron Kuchlani - Lon Hohberger - Luigi Toscano - Maor Blaustein - Marihan Girgis - Marios Andreou - Martin Kopec - Martin Magr - Michael Johnson - Milana Levy - Nicolas Hicher - Pini Komarov - Roman Safronov - Ronelle Landy - Sergii Golovatiuk - Shreshtha Joshi - Soniya Vyas - Steve Baker - Takashi Kajinami - Tobias Urdin - Tristan De Cacqueray - Yadnesh Kulkarni - Yatin Karel The Next Release Cycle At the end of one release, focus shifts immediately to the next release i.e Epoxy. Get Started To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. For those that do not have any hardware or physical resources, there is the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. Get Help The RDO Project has our users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://www.rdoproject.org/community/mailing-lists/. You can also find extensive documentation on RDOproject.org. The #rdo channel on OFTC IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS IRC channels (#centos, #centos-cloud, #centos-devel in Libera.Chat network), however we have a more focused audience within the RDO venues. Get Involved To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and on the OFTC IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube. *Amy Marrich* She/Her/Hers Principal Technical Marketing Manager - Cloud Platforms Red Hat, Inc <https://www.redhat.com/> amy(a)redhat.com Mobile: 954-818-0514 Slack: amarrich IRC: spotz

1 0

Announcing s390x architecture availability for cbs.centos.org/SIGs
by Fabian Arrotin 09 Oct '24

09 Oct '24

As discussed last week (https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/S3X3… ) I reached out to openmainframeproject to see if there would be a possibility to remotely use at least one s390x VM for SIGs. I'm proud to announce that such infra is ready to be used within CBS build infra (https://cbs.centos.org/koji/hostinfo?hostID=22) # What does that mean ? If your SIG wants to start building against/for s390x architecture, please just open a infra ticket on https://pagure.io/centos-infra/issues (usual way) and for which SIG/tags you'd like to see the s390x arch being added. As usual, SIGs can build against rhel8/rhel9/CentOS Stream 9 and CentOS Stream 10, including for s390x (internal mirror is now ready too) # How to proceed There are basically multiple ways to add the s390x architecture : - when you'll create new tag, you can ask for s390x arch to be included by default for your new build tag - for existing tags, you can also ask for the s390x arch to be added, but that also means that builds you'll submit as usual will have to find all build dependencies, including for s390x. It can be that you have yourself built some BuildRequires: dependencies for your RPM packages in your tags, but so probably just for x86_64, aarch64 and eventually ppc64le. How can that specific problem be solved : - either bump nvr for your build chain/order, rebuild in order to include from now on s390x, and then it will be BAU (Business as Usual) once s390x will be at same level for all pkgs. - other possibility (what I just used for the infra tags) : it's possible to just resubmit scratch builds for same package NVR (which koji would refuse you to do as "normal" build) : cbs build --scratch --arch-override s390x <target> <src.rpm/dist-git url> After each successfully scratch build, you can use the build id and then communicate (either through ticket or irc) us the build id, so that we can use a specific (admin right required, reason why SIGs can do that themselves) koji api call, to "merge" the newly s390x build with the existing one (with same pkg NVR, so nothing to do at the src.rpm/git level at all) - other option (if you have plenty of packages in the build chain, and don't want to block other builds for your existing -release tags) : we can create a specific "bootstrap" tag, with only s390x, in which we can just do the scratch+merge dance, until it's all resolved/equal to other tag, and only then, add the s390x arch to your existing tags (that will then automatically find the s390x packages, as existing in koji) One example : I had to rebuild cvs (one of many pkgs I rebuilt), itself a dep for koji-builder (needed to bootstrap the new infra) : - scratch build : https://cbs.centos.org/koji/taskinfo?taskID=4235422 - promoted to existing build : https://cbs.centos.org/koji/buildinfo?buildID=43020 (see s390x artifacts now part of a previous build ID) # Worth knowing We'd like to thank again openmainframeproject for the VM, but also worth knowing that because it's a remote (and locked down) VM, all koji/mirror traffic goes through an encrypted tunnel , and so that has a small impact on the needed time to init a buildroot. Based on my tests, it's still pretty fast to build, but just a little bit slower to init the buildroot, when downloading all needed packages Happy building and let us know which SIG wants to be next SIG (Infra SIG started to rebuild packages for our own usage already) -- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | @arrfab[@fosstodon.org]

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

devel