The Hyperscale SIG will focus on enabling CentOS Stream deployment on large-scale infrastructures and facilitating collaboration on packages and tooling.
What's in scope
In general, we see this SIG as a good place for anything that is beneficial to enabling CentOS Stream deployment in a large-scale production environment, but cannot be directly merged or contributed to CentOS, Fedora or EPEL proper.
Faster-moving package backports
In some environments it can be desirable to track some base packages at a faster pace (e.g. for feature enablement or for ease of interaction with upstream). These are currently maintained internally and independently by various entities, and can be difficult to consume downstream, despite being of general interest. A good example is systemd, which has an actively maintained backport for CentOS at https://github.com/facebookincubator/rpm-backports/tree/master/rpms/systemd that's based on the Fedora packaging.
The SIG aims to maintain these kinds of backports on upstream infrastructure, both to make them easier to consume, and to enable upstreaming changes and improvements whenever possible. The goal is for these backports to be drop-in replacements for the distro-provided packages and to offer the same degree of stability.
Policy and configuration alternatives
There is value in providing alternatives to distro-wide policies at times, especially when they are relatively self-contained. A good example is iptables, which as of CentOS Linux 8 only supports the nftables backend. The SIG would maintain a parallel build of iptables that enables the legacy backend as well.
Enabling large-scale testing for distro-wide changes
We hope the SIG will also provide a space to make it easier to test distro-wide changes to ease their development and integration in the distribution proper. For example, there is ongoing work to enable copy-on-write support in DNF and RPM, which involves changes to much of the packaging stack. While this is something that will definitely be upstreamed in Fedora first (see https://fedoraproject.org/wiki/Changes/RPMCoW), we believe there is value in making it possible to test it easily as part of a production deployment to gather data, if one wishes to.
What's not in scope
In general, anything that can be contributed directly to CentOS, Fedora, EPEL or other upstreams is not in scope. This includes:
- new packages: these should be submitted to Fedora and then EPEL
- packages available in Fedora but not in EPEL: these should be submitted to EPEL
missing -devel and other unshipped packages: these should be submitted to CentOS per FAQ/CentOS8/UnshippedPackages
- bugfixes for packages already part of the distribution: these should be submitted upstream directly
- a set of branches on git.centos.org for the packages the SIG would maintain
- one or more package repositories
Issue-only repo to coordinate SIG business: https://pagure.io/centos-sig-hyperscale/sig
ACL group on ACO: https://accounts.centos.org/group/view/sig-hyperscale
Pagure group: https://pagure.io/group/centos-sig-hyperscale
IRC channel: #centos-hyperscale on Freenode
The SIG uses the centos-devel mailing list for coordination and the #centos-hyperscale IRC channel for interactive comms. The SIG also holds regular bi-weekly meetings on Wednesdays at 16:00 UTC in #centos-meeting. Meetings are logged and the minutes for past meetings are available.
Everybody is welcome to join and contribute to the SIG. The current set of members is:
- Filipe Brandenburger
- Matthew Almond
- Justin Vreeland
- Thomas Mackey
- David Johansen
- Igor Raits
- Neal Gompa
- Anita Zhang
- Michel Salim
The SIG is co-chaired by Davide Cavalca and Justin Vreeland.
Membership can be requested by filing an issue on the SIG tracker or by asking during one of the regular IRC meetings. Current members can raise objection, and in case of disagreement membership requests can be put to a vote, but in general we'd welcome anybody that's interested and willing to do work within the scope of the SIG. We do expect SIG members to actively contribute or otherwise remain engaged with the project, and will initiate removal of stale members after six months of inactivity.