Special Interest Groups

Special Interest Groups (SIG) are smaller groups within the CentOS community that focus on a small set of issues, in order to either create awareness or to focus on development along a specific topic. Each SIG can seek a dedicated section on the wiki, along with an option to display the names of the people involved in that SIG. A mailing list on the CentOS list server can also be setup as well. As proper, and subject to available resources, other resources they might need (eg. a SCM system, web hosting space, admin services, etc.) may be offered.

SIGs, and the process for creating one, are described in more detail in the SIG Guide. Active SIGs hold regular meetings, where you can find out what's happening and how to get involved.

The following SIGs already exist:

0.1. Active SIGs

• Core - Produces the CentOS Linux Distribution

• Alternative Architectures - Extend usability base beyond basic architectures (x86_64), including ARM 64-bit and 32-bit, x86 32-bit, Power 8, and so forth.

• Alternative Images - build and provide alternative iso images for CentOS Stream.

• Artwork - Improving the user experience with high quality artwork

• Automotive - Software related to Automotive

• Cloud - The Cloud SIG will look into issues around running Cloud Infrastructure / Hypervisor for onpremise clouds as well as support other SIGs and projects looking to consume some of the shared resources around on-premise cloud infra

• Config Management - a Special Interest Group to cover configuration management and system lifecycle management on CentOS.

• Hyperscale - Enable CentOS Stream deployment on large-scale infrastructures

• Infrastructure - Coordination of CentOS project infrastructure

• Kmods - Provide kernel modules currently not available in CentOS Stream.

• Messaging - Description needed

• NFV - Network Functions Virtualization (NFV) provides a CentOS-based stack that will serve as a platform for the deployment and testing of virtual network functions (VNFs).

• Operational Tooling - Logging, monitoring and other operational tool development.

• Promo - Promotion and Events

• Public CI - A Public testing and proving infrastructure

• Software Collections - Tools and packages that allow the build, install, and use multiple versions of software on the same system, without affecting system-wide installed packages.

• Storage - Deploying CentOS as a storage node

• Virtualization - Virtualization in and of CentOS

• CentOS Stream Feature Request - A gate for feature requests that are first developed in CentOS Stream from contributors who wish to request these features to be included in future RHEL releases

0.2. Proposed SIGs

Voice your interest and opinion on the centos-devel@centos.org mailinglist if you wish to get involved in any of these efforts.

• Documentation - Encourage and manage CentOS documentation (website, wiki, FAQ)

• Hardening - Deliver a more secure and hardened general purpose kernel and corresponding code

• VoIP - The voice over IP communities run systems in a way that sometimes don't align with conventional business or hosting policies, we should get a group going with skilled domain experience, so we can better address the needs of that community.

• Simplified Linux Server - Menu driven installation and configuration for various services.

• Education - Deliver a pre-contextualised media set for use in Schools, Universities and other education venues

• ARM, Tilera, Mips, Itanium, S390, Alpha, Sparc port

• Alternative Desktop - Add additional desktop oriented software and features

• Hardware compatiblity - Collect information about specific hardware (laptops, devices, printers)

• RPM Packaging

• Translation - In charge of translating CentOS (media, website, wiki, flyer)

• Hosting - Web hosting comes with its own challenges, it would be great to have a specialist group look into the challenges presented there and work on potential solutions from both the provider side and the consumer perspective.

1. Retired/Inactive SIGs

• Atomic - The AtomicSIG aims to build, deliver and maintain an Atomic Host for CentOS Linux. And help bootstrap tooling around the effort.

• Cloud Instance - Look into issues around running CentOS Linux Instances in various private and public clouds

• Xen4CentOS - A Xen 4 (4.4, 4.6, 4.8) implementation for CentOS Linux 6 and CentOS Linux 7. Later absorbed into the Virtualization SIG

• PaaS - Platform as a Service on CentOS

2. Setting up a new SIG

Anyone can propose to setup a SIG, but needs to get the agreement and participation of a member of the CentOS Governing Board. To request a new Special interest group to be started, here is what needs to be done:

• Look at the presently functional SIG's and make sure that your effort will not overlap with another team
• Open a new discussion topic in the CentOS-Devel mailing list, asking for comments
• One of the CentOS Board members will need to join the effort, once that happens then that Board member can :
  • Request a new mailing list to be created (if needed)
  • Request a wiki section to be setup
  • If the SIG needs a version control system to be setup, that can also be requested (refer to the next section on git repo)
  • Get listed as a SIG on this page

Initiating a SIG git repo + koji process:

• SIG must be approved by the Board
• SIG needs to post its proposal to its wiki page
• Chair should do requesting, alternatively the Board member mentoring the SIG can do the request
• Chair requests wiki ACLs for all SIG committee members
• SIG meets with Infra SIG member to discuss how the git repo is going to be setup
• SIG will need a SIG-specific signing key to live on CentOS Project signing server and/or locally to the builder (process needs some improvement here)
• Chair or Board mentor need to request a build tag on bugs.centos.org under buildsys component
• Chair or Board mentor need to request koji targets and tags on bugs.centos.org under buildsys component
• Chair or Board mentor need to request import of SRPMs to be imported in to git.centos.org RPM store, reqest via bugs.centos.org under buildsys component
• Chair or Board mentor need to request koji certs for SIG members on bugs.centos.org under buildsys component
• Chair or Board mentor needs to request a SIG project to be added to bugs.centos.org, or to add a component to another project e.g. CentOS-7

More detailed SIG information may be found in the SIG Guide

3. Requirements

We expect each SIG to meet some basic requirements, these include :

• The topic for the group must be related to CentOS, or a use scenario for CentOS

• There must be adequate control and feedback into the CentOS community

• Generally, all communication as to the work of the SIG should be public, understanding that sometimes a matter may need to be private; in such cases, please consult with the Devteam member out of band of the SIG
• All code produced within the SIG must be compatible with a FOSS license presently used by CentOS; if a new license is wanted, again, please consult with the Devteam member

• All documentation produced within the SIG must be compatible with the license of this wiki

• We would expect teams to be watchful of general CentOS directions from the Devteam

• At least one member of the SIG, who need not be the lead, needs to be a member of the CentOS Devteam. We are not trying to enforce any moderation, however, we feel that the actions of each SIG using CentOS resources needs to have visibility to the Devteam

4. SIG membership

Normally, the following rules for SIG membership apply:

• The mailing lists of the SIGs are open, and can be joined freely.
• SIG members are appointed by the SIG team leader, and may have elevated privileges, like write access to the relevant Wiki section or git repo, depending on the role of the SIG member.
• The SIG team leader may be asked to be a mailing list moderator; generally however, CentOS mailing lists are not moderated.

5. SIG Reporting

SIGs are expected to report quarterly, with a brief summary of what they've accomplished in the past quarter. A suggested outline for this report is as follows:

• Membership update (members added, removed. Chair changes.)
• Releases in the most recent quarter (or most recent release, if none in that quarter)
• Health report and general activity narrative.
• Issues for the board to address, if any

The reporting schedule is currently as follows:

Group 1:

Reports January, April, July, October

• Core
• Config Management
• Software Collections
• Hyperscale
• kmods
• Automotive

Group 2:

Reports February, May, August, November

• Alt Arch
• Cloud
• NFV
• Promo
• Storage
• Messaging

Group 3:

Reports March, June, September, December

• Artwork
• Cloud Instance

• OpsTools

• Public CI
• Virtualization
• Infrastructure

Reports are due by end of business on the first Monday in the designated month, and should be sent to the centos-devel mailing list with a subject line of "[REPORT] XYZ SIG", where 'XYZ' is replaced with the name of your SIG. Reports are to be submitted by the SIG chair.

URL: https://accounts.centos.org

Description: ACO is the place to ask for access to the Community Build System.

Technology: accounts.centos.org is an instance of noggin, deployed in front of merged IPA instances for both Fedora and CentOS Projects (so one account is good for both projects)

Contact: The CentOS Infrastructure Team (#centos-devel on freenode) or the centos-devel mailing list.

Notes:

URL: https://git.centos.org

Description: git.c.o is the authoritative repository of package sources that go into CentOS Linux 7. git.c.o also contains repositories for SIG use and sources for other parts of the CentOS Project

Technology: git.c.o is an instance of Pagure

Contact: The CentOS Sysadmin Team - (#centos-devel on Freenode) or the centos-devel mailing list.

Notes:

URL: http://cbs.centos.org

Description: The Community Buildsystem is where Special Interest Groups build and manage packages for inclusion in their released repos

Technology: CBS is an instance of the Koji buildsystem

Contact: The CentOS Infrastructure Team (#centos-devel on Libera.chat) or the centos-devel mailing list.

Notes:

• Scratch builds on cbs.centos.org currently persist and are not expired, unlike the Fedora Project hosted Koji.
• All image builds must be run as scratch builds at this time

mirror.centos.org is where the content produced by SIGs end up to. mirror.centos.org is served by 50+ servers around the world and GeoIP is used to direct the user to a nearby mirror. The mirror.centos.org machines and their bandwidth are donations to CentOS and they are managed by the CentOS infra team.

While that may sound neat (and it is!) there's an even better option for distributing the files to users. All the content on mirror.centos.org is mirrored by 600+ external mirrors, giving better geographical coverage than what is possible with only mirror.centos.org servers. Using the external mirrors frees up some bandwidth from mirror.centos.org servers, which are also used for syncing the content to those external mirrors. You can use the external mirrors by specifying a mirrorlist option in your repository config file. Details about this can be found in the "Building a centos-release-* package" section.

Describe Properties/Devcloud here.

Anyone may propose and/or participate in a Special Interest Group, here are some guidelines and tips related to the workings of a SIG.

0.1. Proposal

Creating a new SIG requires participation from a member of the CentOS Governing Board, and a SIG must meet some requirements:

0.1.1. Requirements

1. The topic must be related to CentOS, or a use scenario for CentOS
2. There must be adequate control and feedback into the CentOS community
3. Generally all communication as to the work of the SIG should be public, understanding that sometimes a matter may need to be private. In such cases, please consult with the sponsoring Governing Board member
4. All code produced within the SIG must be compatible with a FOSS license presently used by CentOS
5. All documentation produced within the SIG Must be compatible with the license of this wiki
6. SIGs should be mindful of general CentOS directions from the Governing Board
7. One member of the SIG should be a member of the Governing Board/Devteam

0.1.2. The Proposal Process

1. Check to see if the topic of collaboration is already covered by an existing SIG
2. Post an introductory 'RFC' email to the centos-devel mailing list and ask for comments
3. Find a CentOS Governing board member to join the effort
4. The board member will:
   1. Request any initial resources be created

   2. List the SIG on the SpecialInterestGroup page in the wiki

      • See the SpecialInterestGroup/ProposalTemplate page for a template of things to include on the SIG's wiki page

0.2. Acceptance

The sponsoring member of the Governing board will put the proposal at a regularly scheduled board meeting. The Board will, if the proposal is accepted, give its charter to the SIG to begin its work.

SIG founders should stay in close contact with their sponsor through this process to work out any questions arising from the proposal.

0.3. Account Setup

0.3.1. Community Buildsystem

0.4.1. ci.centos.org

0.4.2. Devcloud

0.5. Requesting Resources

0.5.1. Content Signing Key

0.5.2. Mailing Lists

0.5.3. IRC Channels

0.5.4. Bug 'Projects' in tracker

The SIG Sponsor (board member) handles requests for a SIG Project in https://pagure.io/centos-infra/issues/.

The SIG should agree on this at a regularly scheduled meeting and contact the sponsor for next steps.

0.5.5. SIG Bot accounts for CBS

Some SIGs may want to use a bot account for automated builds in CBS from CICO or other infrastructures.

0.5.5.1. Requirements

1. The account name is the shortname of the sig (cloud, configmanagement, cloudinstance) etc

2. The email on the account must be deliverable to someone who can change the certificate in the production environment

The account approval process follows the usual sponsorship model. Be sure to notify one of the ACO admins and they will sponsor the account into the appropriate group.

0.5.6. CBS Tags

To request new tags in CBS open a request

Be sure to include the following information:

• The name of the SIG
• The SIG project
• The release string of the project (if any)

Tags in CBS follow the following format: <signame><centos_version>-<project>-<release_string>-{candidate,release,testing}

Example: cloud7-openstack-kilo-testing

If the requestor is not the SIG Chair, the Chair should comment on the bug with a +1 or -1 to approve or deny the new tags.

0.6. Daily Workings (Meetings)

Package sources checked into git.centos.org are in exploded SRPM format. This means that the package working directory should have at least a SPECS/ subdirectory.

0.1.0.1. New Package (from source)

If the package you'd like to build isn't yet on https://git.centos.org, create first a ticket on https://pagure.io/centos-infra/issues to request the git repo for /rpms/<your_package> to be created

Once it will be created, it will be possible for you to push to *specific* branches, based on the following rules: c{7,8}-<sig_name>*

So that means that if I'm member of the sig-core group (in ACO), I'll be able to commit/push to c8-sig-core or c8-sig-core-whatever-I-want branches

Let's use the following example : I need to create a branch for pkg centpkg-minimal, and I'm member of the sig-core SIG group. We have to push two things to git.centos.org :

• .spec files to build a src.rpm
• eventually blob (.tar.gz archive) that will need to be pushed to lookaside cache

Warning : to push to lookaside cache you need to have already a local check out from https://git.centos.org/centos-git-common

0.1.0.2. Pushing first to lookaside cache

Let's assume that my pkg centpkg-minimal that I want to build has an archive called centpkg.minimal.tar.gz. To be able to push to lookaside cache, we need the following :

• a valid TLS cert (also needed to build on cbs.centos.org) obtained through centos-cert util
• lookaside_upload script in your $PATH (coming from centos-git-common git repo, see above)

This simple script would need some paramters:

lookaside_upload 

You need to call the script like this : ~/bin/lookaside_upload -arguments

        -f : filename/source to upload (required, default:none)
        -n : package name for that source (requred, default:none, example "httpd")
        -b : "branch" where to upload to (required, default:none, example "c7-sig-core")
        -h : display this help

So back to our example, the pkg name is centpkg-minimal, file is centpkg-minimal.tar.gz and I'm member of the sig-core group, and want to build it for c7, so we'll call it like this :

lookaside_upload -f centpkg-minimal.tar.gz -n centpkg-minimal -b c7-sig-core
[+] CentOS Lookaside upload tool -> Checking if file already uploaded
[+] CentOS Lookaside upload tool -> Initialing new upload to lookaside
[+] CentOS Lookaside upload tool -> URL : https://git.centos.org
[+] CentOS Lookaside upload tool -> Source to upload : centpkg-minimal.tar.gz 
[+] CentOS Lookaside upload tool -> Package name: centpkg-minimal
[+] CentOS Lookaside upload tool -> sha1sum: d6616b89617914a0dd0fd5cfa06b0afc7a4541c4
[+] CentOS Lookaside upload tool -> Remote branch: c7-sig-core
[+] CentOS Lookaside upload tool ->  ====== Trying to upload =======

################################################################################################################ 100.0%
File centpkg-minimal.tar.gz size 15178 CHECKSUM d6616b89617914a0dd0fd5cfa06b0afc7a4541c4 stored OK
[+] CentOS Lookaside upload tool -> Validating that source was correctly uploaded ....
[+] CentOS Lookaside upload tool -> [SUCCESS] Source should be available at https://git.centos.org/sources/centpkg-minimal/c7-sig-core/d6616b89617914a0dd0fd5cfa06b0afc7a4541c4

Now that we have uploaded to lookaside cache, we can reference it in our /rpms/centpkg-minimal git repository on git.centos.org, see below

0.1.0.3. Pushing to git.centos.org

We should already have a local checkout of the git repository for the pkg we'd like to work on. In our case, the git repo url is https://git.centos.org/rpms/centpkg-minimal

So the way to git clone/pull over ssh is so ssh://git@git.centos.org/rpms/centpkg-minimal.git :

git clone ssh://git@git.centos.org/rpms/centpkg-minimal.git
Cloning into 'centpkg-minimal'...
remote: Counting objects: 15, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 15 (delta 2), reused 0 (delta 0)
Receiving objects: 100% (15/15), done.
Resolving deltas: 100% (2/2), done.

Important : You can clone over https, but then it wouldn't let you push back to it, as it needs ssh with key verification and based on group membership for acls

Let's create a new c7-sig-core branch (still based on the assumption that I want to build for c7) :

git checkout -b c7-sig-core

You can now create your SPECS/<pkg_name>.spec and add also other text patches under SOURCES/ We still need also to point to /sources/ for the lookaside cache, so we'll use the value of the hash returned when we successfully uploaded to lookaside cache and we'll write a .<pkg_name>.metadata file in the root dir that will look like this in our example:

d6616b89617914a0dd0fd5cfa06b0afc7a4541c4 SOURCES/centpkg-minimal.tar.gz

Now that we have pointer to lookaside cache, and also .spec, we can push back to git and we should be able to proceed with the "build-from-git" on cbs.centos.org. Let's commit first :

# git add <files> # if needed
git commit -a 
git push origin c7-sig-core # to create the c7-sig-core branch on git.centos.org if not existing yet

The current workflow for submitting builds to CBS is to generate a Source RPM in the developer's working directory for submission to the builders. A developer needs an active CBS account and the client tools installed on their workstation (see SIGGuide#CBSAccount).

0.2.0.1. Generating a Source RPM

Still allowed for now and for --scratch builds, but building from git.centos.org is the way to go

[bstinson@localhost new-package]$ rpmbuild --define "%_topdir `pwd`" -bs SPECS/new-package.spec

0.2.1. Short detour to describe Tags and Targets

When building in CBS it helps to understand where to send the sources to start a build, and where the built packages will come out the other end.

0.2.1.1. Definitions

• Build Target: Specifies the buildroot and destination of a package for submission. This is specified on the /usr/bin/cbs command line to direct the package into the correct place

• Tag: A place for packages to be grouped together. Built packages can be added to a tag automatically (e.g. just after a build) or manually placed in a tag with the tag-build operation to /usr/bin/cbs

0.2.1.2. Build Targets

Build targets are named according to the CentOS version, SIG, Project, Project Version, and Disttag they represent. Taking cloud7-openstack-kilo-el7 as an example:

The build target will be assigned when a new set of tags is requested, and a list of current targets can be found at http://cbs.centos.org/koji/buildtargets

0.2.1.3. Tags

When a chairperson requests a new set of build tags, the SIG is encouraged to adopt the default workflow:

[build] -> cloud7-openstack-kilo-candidate -> cloud7-openstack-kilo-testing -> cloud7-openstack-kilo-release

The buildroot for new packages includes repositories from:

• The CentOS Linux base operating system
• A collection of the latest builds of every package in the candidate tag.

This allows developers to satisfy dependencies by relying on content in the base OS or by making sure a proper version is tagged in to -candidate (either by building it through the corresponding build target, or by issuing the tag-build command to include an already-existing build).

0.2.1.4. Build!

New Packages:

If your package has not been built before add it to the package list on your destination tags:

[bstinson@localhost new-package]$ cbs add-pkg --owner=bstinson cloud7-openstack-kilo-candidate new-package
[bstinson@localhost new-package]$ cbs add-pkg --owner=bstinson cloud7-openstack-kilo-testing new-package
[bstinson@localhost new-package]$ cbs add-pkg --owner=bstinson cloud7-openstack-kilo-release new-package

Scratch Build:

# Sending a source RPM to a scratch build
[bstinson@localhost new-package]$ cbs build --scratch cloud7-openstack-kilo-el7 SRPMS/new-package-1.0.1-2.el7.src.rpm

Scratch builds will show up in the CBS web interface, and the built RPMS will be downloadable from there, but the package will not be included in any of the CBS tags (or the repos generated from the tags). Scratch builds are used to test functionality before doing a proper tagged build.

Tagged (Normal) Build:

# Sending a source RPM to a build target 
[bstinson@localhost new-package]$ cbs build cloud7-openstack-kilo-el7 SRPMS/new-package-1.0.1-2.el7.src.rpm

Tagged builds will end up in the -candidate tag after it's finished building, and will be available in the buildroot in case other packages depend on it.

NOTE: There is a restriction in CBS that a package's Name-Version-Release must be globally unique. This means that if anyone else (even from another SIG) has built new-package-1.0.1-2.el7 you must use that build, or build a different version

0.2.1.5. Building from git.centos.org

Instead of building locally a .src.rpm pkg and upload it to CBS to be built, you can submit a build request pointing to git.centos.org (see previous steps about lookaside and git push).

You just have to call cbs build pointing to git+https://git.centos.org/rpms/<pkg_name>.git#<commit_hash>

If you followed our previous example about centpkg-minimal package, we can easily retrieve from our git history the commit hash for the c7-sig-core branch that we just pushed to git.centos.org :

git log|head -n 1
commit ca63b53c8bde1efc91d55548f194dbecbf457cad

So to tell cbs builders to automatically retrieve all from git.centos.org (.spec / patches and lookaside artifact declared in .<pkg_name>.metadata) we can call it like this (based on our example and infrastructure7-el7 being our target for cbs tags, so it depends on your SIG/tags):

cbs build infrastructure7-el7 git+https://git.centos.org/rpms/centpkg-minimal.git#ca63b53c8bde1efc91d55548f194dbecbf457cad

0.2.1.6. Frequent Error Messages

• FAILED: BuildError: package new-package not in list for tag cloud7-openstack-kilo-candidate

  • Be sure you add the package to the list be sure to add it to the package list: See the New Packages section under the Build step

Describe SIGGuide/Content/Testing here.

There are 2 points in the process where packages can be promoted for wider consumption. Testing content can be distributed to the buildlogs.centos.org content delivery network for developers and CI systems to consume. Release-ready content can be promoted to a SIG-specific directory on mirror.centos.org for consumption by end-users.

As a first step, decide on the final release location of the repo on mirror.centos.org. You can use the same path for buildlogs.centos.org.

• Example: OpenStack Rocky for CentOS 7 lives at http://mirror.centos.org/centos/7/cloud/x86_64/openstack-rocky/

0.4.1. Pushing Test Content to Buildlogs

0.4.2. Releasing content to mirror.centos.org

0.4.3. centos-release Packages