Packaging and maintaining kernel modules for CentOS Stream.
The SIG elected Peter Georg and Jonathan Billings as co-chairs.
No SIG members have been added since the SIG has been approved (June 9th).
No packages have been released yet.
The Kmods SIG has been approved recently. So far it has mainly been busy with bootup activities and establishing packaging guidelines.
Regular meetings are scheduled every two weeks (on even weeks) on Monday 1500 UTC in #centos-meeting. Everyone is welcome to join!
We have no issues to bring to the board’s attention at this time.
This report covers work that happened between April 2nd and June 30th. For previous work, see the 2021Q1 report.
The Hyperscale SIG focuses on enabling CentOS Stream deployment on large-scale infrastructures and facilitating collaboration on packages and tooling.
Since the last update, the SIG gained one new member (Jim Heald).
We welcome anybody that’s interested and willing to do work within the scope of the SIG to join and contribute. See the membership section on the wiki for the current members list and how to join.
Unless otherwise specified, packages are available in our main repository, which can be enabled with
dnf install centos-hyperscale-release. Please report any issues with these packages on our package-bugs tracker.
systemd-oomd was declared stable in systemd 248 and was adopted in Fedora 34 as the default userspace out-of-memory killer. It monitors memory pressure thresholds and kills processes at the cgroup level. The
systemd-oomd-defaults package, which provides the policy used by Fedora, is also backported to our repository.
In addition to release builds, we’re also producing daily systemd builds via the CentOS CI infrastructure. These builds track the upstream git head and can be useful to test the latest changes and features, while also helping spot potential build issues ahead of time.
A non-modular version of the LLVM 12 compiler suite is now shipped in Hyperscale. This is meant as a stopgap, and will be removed once a modular version of LLVM 12 becomes available in CentOS Stream proper.
Because this is a set of non-modular packages overriding a module, it is being delivered in a new repository to be used as a modularity hotfix repository. This repository can be enabled with
dnf install centos-release-hyperscale-hotfixes.
An updated packaging stack (rpm, dnf, libdnf, librepo) is now available in the experimental repository. These packages include several improvements and bugfixes to support the ongoing Copy-on-Write work. The experimental repo can be enabled with
dnf install centos-release-hyperscale-experimental.
We have a 5.12.4 release of the Linux kernel currently in our experimental repository. This kernel has btrfs and Kernel Live Patching enabled. We’ve taken steps to ensure our nascent kernel process is compatible with kernel-ark to enable smoother updates and CI.
We ship a modified version of kpatch 0.9.3 that includes a few additional backports from upstream. Our packaging of kpatch also includes the
kpatch-build tool, which can be used to convert kernel patches to be then applied onto a system that supports Kernel Live Patching.
We have rebuilt a number of components to restore Btrfs support:
and built a backport of
btrfs-progs. Additionally, we have branched and built the Anaconda installer based on version 220.127.116.11 with support for Btrfs restored and a number of backports from Anaconda 34 to enable building spins based on Hyperscale content. Our version of the installer also includes the
anaconda-live package for supporting installation from live media.
A minimal container image based on the Hyperscale SIG repos and packages is now available on Quay.io and can be used via Docker or Podman:
podman run -a stdin,stdout,stderr -t quay.io/centoshyperscale/centos:stream8
This container image is built from scratch, and in the future we plan to leverage the CentOS CI infrastructure to automate the build process.
An experimental CentOS Hyperscale Workstation Live DVD image is now available. This image is currently based on the GNOME desktop shipped in CentOS Stream 8 and is combined with the packages we’ve shipped in the Hyperscale SIG, notably the live installer and storage stack software. A KDE Plasma variant is forthcoming.
Issues with this image can be reported on our spin-bugs tracker.
We ship an updated backport of libvirt 7.1.0. Due to CBS being unable to build modules, this is shipped as a non-modular package in the hotfixes repository mentioned earlier.
We have announced the availability of a mock-centos-sig-configs project to hold mock configurations for CentOS SIGs. The goal is to make it easier to build packages against a given SIG when doing local testing and development. The project currently contains configs for the Hyperscale SIG, but other SIGs are welcome to contribute their configs as well.
There are several other backports we’re shipping within the SIG:
We’re also made available a modified version of util-linux 2.32.1 that includes support for
setpriv --reset-env and for the
The SIG continues to maintain a healthy development pace.
The SIG uses the
#centos-hyperscale IRC channel for ad-hoc communication and work coordination, and the centos-devel mailing list for async discussions and announcements. As of April, the SIG also holds open monthly video conference sessions to promote collaboration and social interaction.
As of June, Neal Gompa has been streaming ad-hoc SIG-related work sessions on his Twitch channel. To this end, we have created a dedicated CentOSHyperscale channel that we plan to use going forward to promote and collate SIG related content.
The SIG tracks pending work as issues on our Pagure repository. Notable projects currently in flight include:
We have no issues to bring to the board’s attention at this time.
This is a followup to our earlier post regarding CentOS' move to the Libera IRC network.
Thanks primarily to the efforts of John "Bahhumbug" and our other IRC ops, the move has been completed, and all channels have been moved from Freenode to irc.Libera.chat, complete with the topics, bots, access lists, and supporting documentation.
Note also that we have a list of channels in the wiki, which includes channels for specific topics, such as #centos (our general/main channel), #centos-devel for developer and other technical questions, #centos-stream for CentOS Stream specific questions, and several others.
You will need to re-register your user account on Libera, as these were not migrated over.
We look forward to seeing you on Libera.chat!
The CentOS Board of Directors is delighted to welcome two new directors - Davide Cavalca and Josh Boyer - to the Board.
Please join us in welcoming them, and thanking them for their willingness to dedicate some of their time to the endeavor of steering the CentOS Project.
Once again, we thank outgoing directors Karsten Wade and Carl Trieloff for their years of service.
Release for CentOS Linux 8 (2105) We are pleased to announce the general availability of the latest version of CentOS Linux 8. Effectively immediately, this is the current release for CentOS Linux 8 and is tagged as 2105, derived from Red Hat Enterprise Linux 8.4 Source Code. As always, read through the Release Notes at: http://wiki.centos.org/Manuals/ReleaseNotes/CentOS8.2105 - these notes contain important information about the release and details about some of the content inside the release from the CentOS QA team. These notes are updated constantly to include issues and incorporate feedback from users. ---------- Updates, Sources, and DebugInfos Updates released since the upstream release are all posted, across all architectures. We strongly recommend every user apply all updates, including the content released today, on your existing CentOS Linux 8 machine by just running 'dnf update'. As with all CentOS Linux 8 components, this release was built from sources hosted at git.centos.org. Sources will be available from vault.centos.org in their own dedicated directories to match the corresponding binary RPMs. Since there is far less traffic to the CentOS source RPMs compared with the binary RPMs, we are not putting this content on the main mirror network. If users wish to mirror this content they can do so using the reposync command available in the yum/dnf-utils package. All CentOS source RPMs are signed with the same key used to sign their binary counterparts. Developers and end users looking at inspecting and contributing patches to the CentOS Linux distro will find the code hosted at git.centos.org far simpler to work against. Details on how to best consume those are documented along with a quick start at: http://wiki.centos.org/Sources Debuginfo packages have been signed and pushed. Yum configs shipped in the new release file will have all the context required for debuginfo to be available on every CentOS Linux install. This release supersedes all previously released content for CentOS Linux 8, and therefore we highly encourage all users to upgrade their machines. Information on different upgrade strategies and how to handle stale content is included in the Release Notes. Note that older content, obsoleted by newer versions of the same applications are trim'd off from repos like extras/ and centosplus/ ---------- Download We produced the following installer images for CentOS Linux 8 # CentOS-8.4.2105-aarch64-boot.iso: 677838848 bytes SHA256 (CentOS-8.4.2105-aarch64-boot.iso) = 106d9ce13076441c52dc38c95e9977a83f28a4c1ce88baa10412c1e3cc9b2a2b # CentOS-8.4.2105-aarch64-dvd1.iso: 7325042688 bytes SHA256 (CentOS-8.4.2105-aarch64-dvd1.iso) = 6654112602beec7f6b5c134f28cf6b77aedc05b2a7ece2656dacf477f77c81df # CentOS-8.4.2105-ppc64le-boot.iso: 722780160 bytes SHA256 (CentOS-8.4.2105-ppc64le-boot.iso) = 4a83e12f56334132c3040491e5894e01dfe5373793e73f532c859b958aeeb900 # CentOS-8.4.2105-ppc64le-dvd1.iso: 8484990976 bytes SHA256 (CentOS-8.4.2105-ppc64le-dvd1.iso) = 9cfca292a59a45bdb1737019a6ac0383e0a674a415e7c0634262d66884a47d01 # CentOS-8.4.2105-x86_64-boot.iso: 758120448 bytes SHA256 (CentOS-8.4.2105-x86_64-boot.iso) = c79921e24d472144d8f36a0d5f409b12bd016d9d7d022fd703563973ca9c375c # CentOS-8.4.2105-x86_64-dvd1.iso: 9928966144 bytes SHA256 (CentOS-8.4.2105-x86_64-dvd1.iso) = 0394ecfa994db75efc1413207d2e5ac67af4f6685b3b896e2837c682221fd6b2 Information for the torrent files and sums are available at http://mirror.centos.org/centos/8/isos/ -------- Additional Images Vagrant and Generic Cloud images are available at: http://cloud.centos.org/centos/8/ Amazon Machine Images for Amazon Web Services are published by ID into a number of regions. A table of AMI IDs can be found here: https://wiki.centos.org/Cloud/AWS ---------- Getting Help The CentOS ecosystem is sustained by community driven help and guidance. The best place to start for new users is at http://wiki.centos.org/GettingHelp We are also on social media, you can find the project: on Twitter at :http://twitter.com/CentOS on Facebook at :https://www.facebook.com/groups/centosproject/ on LinkedIn at :https://www.linkedin.com/groups/22405 And you will find the core team and a majority of the contributors on irc, on irc.Libera.chat in #centos ; talking about the finer points of distribution engineering and platform enablement. ---------- Contributors This release was made possible due to the hard work of many people, foremost on that list are the Red Hat Engineers for producing a great distribution and the CentOS QA team, without them CentOS Linux would look very different. Many of the team went further and beyond expectations to bring this release to you, and I would like to thank everyone for their help. We are also looking for people to get involved with the QA process in CentOS, if you would like to join this please introduce yourself on the centos-devel list (http://lists.centos.org/mailman/listinfo/centos-devel). Finally, please join me in thanking the donors who all make this possible for us. Enjoy the fresh new release! Thanks, Johnny Hughes
Quorum and started at :05
Directors in attendance were:
Others in attendance:
Topic: CentOS Stream Feature Request SIG approval
Topic: Departure of Board members and Board nominations
Proposal: Monthly meeting with the community to discuss board meeting outcome
Reviewed issues :
Adjournment at :38
Thank you to everyone who responded to my call for feedback on the SIG process. A few people responded on-list. More people responded off-list. I’ve summarized common complaints, and in a few cases provided comments verbatim - especially when they already went to a public list.
Please see the centos-devel mailing list for further discussion of what happens next.
The following areas were identified by one or more people as pain points in the SIG process.
Several people said that we do a poor job of communicating what SIGs are for, what should be a SIG, whether something should be a SIG or part of EPEL, and, in general, what the value of a SIG is.
When SIGs were introduced, they were meant to provide an incubator for projects in the CentOS space and also to provide infra/space to give projects a chance to CI test within CentOS, i.e "how does your project work on CentOS?" Has that focus been dropped? If not, would it be a good idea to reinforce the message?
We need to make it clear that Red Hat still has an interest in CentOS. That message would also be valuable for [Red Hat employees]. CentOS is an important place to put Red Hat’s “upstream first” message into action, but this often gets ignored.
Almost everyone said that the proposal process was vague and opaque.
It is unclear what the board is looking for in a proposal. While there is a template - https://wiki.centos.org/SpecialInterestGroup/ProposalTemplate - examples of good proposals, and what kind of specific things the board will look for, would make this process easier.
Access to the wiki to post the initial proposal is a bit of a chicken-and-egg - that is, without a SIG, who has authority to edit a wiki page for the SIG?
The deliberation/discussion of the proposal should happen on-list, not hidden/secret in board meetings. This will also give other potential projects insight into what they should be thinking about in their proposals.
Several people said that onboarding was confusing and undocumented, and seemed to assume you already know what you’re supposed to do.
Note: Several people specifically called out Fabian Arrotin as being extremely helpful in this setup process, with the caveat that he may not scale if we start getting more SIGs onboarding.
The “what’s next” after a SIG has been approved is very unclear. Once approved, what is the process for getting resources set up?
In the past, the SIG onboarding was often gated on one person, and getting their attention was difficult. This should be better with the new Infra sig.
One of the biggest hurdles is the repo setup (deciding on the cbs/koji setup, naming, setting up repositories for mirrors, etc). If you have never touched koji before, this is going to be tough for you. We need much better onboarding documentation for beginners, along with recommended best practices.
If you’re not a Red Hat “insider,” there’s a good chance that your SIG proposal will be ignored, or at least not given priority. The onboarding for [several SIGs] too more than a year - not because it was controversial, but because nobody prioritized it.
A number of respondents commented from the contributor side, about the lack of information/communication from SIGs.
The SIG wiki page says that quarterly reporting is required, but the majority of SIGs do not report, and there is no consequence for failing to report.
It is very difficult to find out from the SIGs themselves what opportunities there are for involvement. One respondent replied “I'd like to be more deeply involved in the [name] SIG. It's always a surprise to me how much I push to be a part of the group and how little opportunity there is.” SIGs need to be much more proactive in what volunteer opportunities there are.
Some SIGs have weekly meetings, some monthly, and some never meet. This is very frustrating to people who want to get involved in the SIGs, but don’t know where to start.
Having an easier, documented way to contact a SIG with questions or offers of help is needed. Right now, we have out-of-date wiki pages with inaccurate lists of SIG members, and no way to contact them even if it was accurate.
SIG wiki pages must be updated with current information. They should also have a standard format, so that basic required information is always available.
Several developers complained that they were just expected to know what to do, and not provided much guidance or advice as to how to proceed.
Clearer documentation (or pointers to documentation elsewhere) about package building, and how to set up a CI environment.
It would help if every SIG had the same buildroot setup, so that you know what to expect, and moving from one SIG to another was easier. This will increase cross-SIG engagement.
Developer experience on git.centos.org and CBS. Notably:
- the way the lookaside works: https://pagure.io/centos-infra/issue/259
- hard to discover clone URLs: https://pagure.io/centos-infra/issue/245
- support for modularity in CBS: https://pagure.io/centos-infra/issue/294
The PR workflow in particular is problematic -- right now we rely on SIG members pushing directly to the repos, which makes code review difficult. It's also a blocker for external contributions (as, though one can technically put up a PR, there is no way to actually merge it).
I would love to have something closer to the workflow in Fedora. specifically:
- allow SIG members to review and merge PRs onto their branch
- kick off scratch builds on PRs to get signal
We need a way for SIGs to publish structured documentation on docs.centos.org, akin to the "quick docs" model that Fedora uses.
Missing -devel subpackages (I know this has been discussed a lot and fix is in progress).
I'd like to build, tag and push release rpms (as centos-release-openstack). In CentOS7 we could build and tag by ourselves (although it needed infra action to push). In CentOS8 we need to rely on CentOS infra to build and publish them in extras repos.
TL;DR: #centos and #centos-* are moving to libera.chat
Over the past few days, there has been some upheaval on the Frenode IRC network, resulting in a number of the staff members quitting and starting a new IRC network. I don't wish to explain all the details here, but you can read more at https://kline.sh which also links to other sources.
The various ops have discussed the situation, and we intend to migrate all of the various #centos-* channels from Freenode over to libera.chat over the coming days.
This will take time, since libera is still spinning up, and some servers are moving from one network to the other.
As libera is still in the early stages of setup, you may have significantly more timeouts/disconnects, netsplits and other issues for now. Until the new network is fully stable, we'll all continue to be present in the Freenode channels.
Please bring further questions to the IRC channels, which you can join on irc.libera.chat.
The Community Platform Engineering group, or CPE for short, is the Red Hat team combining IT and release engineering from Fedora and CentOS. Our goal is to keep core servers and services running and maintained, build releases, and other strategic tasks that need more dedicated time than volunteers can give.
See our wiki page here for more information: https://docs.fedoraproject.org/en-US/cpe/
We are hiring new talent to come work full time on Fedora and CentOS. The following positions are now open:
Please note that due to a constraint in how the jobs system works, a single country is nominated for the advertisement. Please kindly ignore that, two of the roles are available in the geographical regions outlined above.
We are looking forward to meeting you and hopefully working with you soon!