devel

devel@lists.centos.org

11 participants
4618 discussions

Re: devel Digest, Vol 237, Issue 3
by Pierre De Jager 25 Nov '24

25 Nov '24

Please unsubscribe me On Mon, Nov 25, 2024 at 5:41 PM <devel-request(a)lists.centos.org> wrote: > Send devel mailing list submissions to > devel(a)lists.centos.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > devel-request(a)lists.centos.org > > You can reach the person managing the list at > devel-owner(a)lists.centos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of devel digest..." > > Today's Topics: > > 1. CentOS bootc images - Where should they go (Troy Dawson) > 2. Re: CentOS bootc images - Where should they go (Neal Gompa) > 3. Re: CentOS bootc images - Where should they go (Troy Dawson) > 4. Re: CentOS bootc images - Where should they go (Fabian Arrotin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Nov 2024 07:00:54 -0800 > From: Troy Dawson <tdawson(a)redhat.com> > Subject: [CentOS-devel] CentOS bootc images - Where should they go > To: "The CentOS developers mailing list." <centos-devel(a)centos.org> > Message-ID: > < > CAKndyURTg52b6JwzgjddYDiW-gE9b6-RB30GL7ejz6NxcgBO6w(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="00000000000077ac470627be00b8" > > The CentOS Alternative Images SIG has recently been asked about making > CentOS bootc images.[1] > > Investigation is showing that we should be able to. But that leads to the > next question. After we build them, where would they go? > > (A) Initial thoughts are someplace in the CentOS SIG infrastructure. But > there currently isn't anything setup for serving containers. It's also not > the first place people would look. > > I was thinking of having them on quay.io. > But if we do publish our bootc/container images on quay.io, where? > > (B) centos:<some-name> ? > That would mean that the SIG's would have access to that account. > I also don't know what we would have for <some-name>. > We would have to have something different for each SIG. > > (C) centos-sig:<some-name> ? > The SIG's would still have to share authentication in some manner. > I still don't know what to do for the names. > > (D) centos-<sig-name>:<some-name> > The SIG's would have their own authentication. > The sig's would have control of their own naming convention. > centos-altimages:stream10-bootc > centos-altimages:stream10-bootc-kde > centos-isa:stream9-bootc-baseline > centos-isa:stream9-bootc-optimized > There are some drawbacks for this. Someone would have to know the SIG name > to find the image. Possibly other things. > > I personally am leaning towards (D). But I could be persuaded towards the > others. And it's possible I haven't even thought of the correct solution. > > Ideas / thoughts / comments welcomed and wanted. > > Troy > > [1] - https://pagure.io/centos-sig-alt-images/sig/issue/10 >

1 0

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

← Newer
1
2
3
4
5
6
7
8
9
...
462
Older →

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