Spike: Research alternative for CentOS 8 packages

changed due date to November 05, 2021

changed milestone to %14.5

added Deliverable [deprecated] Accepting merge requests devopssystems groupdistribution maintainer-discussion priority1 sectioncore platform labels

One aspect worth considering with this is if the main cloud providers support the OS officially. I.E. Are they providing official images to create VMs with?

Having a quick look:

GCP: Has Rocky Linux, not Alma
AWS: None in their official list but both Rocky and Alma are available in the marketplace from the projects
Azure: None in their official list but both Rocky and Alma are available in the marketplace from third parties

And this is only "top" AMER based cloud providers. This says nothing of other major vendors, or even hardware vendors.

The "Alma vs Rocky" discussion has a lot of things to be considerate of, including life expectancy, commercial backing (sponsors), enterprise support (and track record of those vendors), and more factors.

A reasonable contender is also the use of Red Hat Universal Base Images (UBI) (licensing FAQ, FAQ) as the basis for building the Omnibus GitLab packages, and then distributing the result to CentOS variants. This actually "flips" the existing model, where we packaged in CentOS, and distributed for variants & RHEL.

Things that have to be taken into consideration, and thoroughly tested:

Building on UBI vs CentOS and requirements there-of, regarding packages, compliance, compatibility.
Verification portability / compatibility claims by UBI / RHEL / Alma / Rocky / ...

changed the description

@dorrino @WarheadsSE - I added more detail and background to the description. Please review and edit as needed. Given the attention that this issue will likely have, presenting the context will be important.

changed the description

mentioned in issue gitlab-org/quality/triage-reports#5171 (closed)

mentioned in issue gitlab-org/omnibus-gitlab#6327 (closed)

Adding context from Packagecloud regarding CentOS alternatives:

https://packagecloud.io/blog/what-is-centos-where-did-centos-come-from-where-did-centos-start/#strongFuture-of-CentOSstrong

assigned to @rmarshall

@greg @lbot what is your perspective from Support, to support both Alma and Rocky?

The reason we requested Gitlab to support Gitlab running on AlmaLinux is the following. Hope this helps with your assessment.

We picked AlmaLinux because we were already working directly with CloudLinux on their service called KernelCare.

KernelCare has been an awesome addition to our production portfolio. We decided that with CloudLinux backing AlmaLinux, it would make sense to use AlmaLinux.

@thomas.gabrieljoseph You've also mentioned that AlmaLinux has passed your Security review. Can you share any of those results with us?

added to epic gitlab-org&7084 (closed)

removed from epic gitlab-org&7084 (closed)

mentioned in issue gitlab-org/quality/triage-reports#5285 (closed)

Enterprise Linux distributions are built from the same source and, except for os-release and GPG keys, identical. During testing of AlmaLinux and Rocky Linux, we found that packages from any binary Red Hat Enterprise Linux distribution worked with each as one would expect.

For this reason, we will officially support all distributions that are binary compatible with Red Hat Enterprise Linux.

Reviewing our options, we think our best path is to build using AlmaLinux. AlmaLinux is backed by a company with a long track record of building an enterprise Linux compatible distribution and has the processes in place to sustain it. This aligns to our preference for the boring solution. AlmaLinux also keeps us in alignment with our community members who prefer to run enterprise Linux without the requirement to sign up for licensing agreements, even when those licensing agreements are free of charge.

For today's usage, our GitLab 14.5 builds in CentOS should just work in AlmaLinux. We can schedule work to build out validation and testing and migrate toward AlmaLinux as our base builder for the longer term.