remove Centos 8 from Helix as it is EOL

[wfurt]

It is EOL https://www.centos.org/centos-linux-eol/ as December 31st, 2021 and we no longer produce docker images dotnet/dotnet-buildtools-prereqs-docker#622

contributes to #75262

cc: @tmds @omajid @danmoseley

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

It is EOL https://www.centos.org/centos-linux-eol/ as December 31st, 2021 and we no longer produce docker images dotnet/dotnet-buildtools-prereqs-docker#622

contributes to #75262

cc: @tmds @omajid @danmoseley

Author:	wfurt
Assignees:	wfurt
Labels:	area-System.Net.Quic
Milestone:	-

[karelz]

Just curious if we should start testing CentOS Stream instead, or if coverage of Fedora + RHEL is sufficient in the space ... any thoughts @wfurt?

[wfurt]

Some background reading: https://thenewstack.io/centos-9-stream-is-now-available-but-should-you-use-it/

Seems pretty close to Fedora (34) -> may not need separate run.

CentOS Stream is a continuous-delivery distribution serving as the next point-release of RHEL.

so this is going be ongoing battle. This may work great for live systems but it seems like this is going to be more tricky with container rebuilds and manual updates in runtime.

Perhaps @tmds @omajid and comment on what would give us best coverage while minimizing runs.

[omajid]

A couple of thoughts.

• The CentOS 8 leg, in my mind, was kind of a stand-in for RHEL 8. We have RHEL 7 in the matrix (RedHat.7.Amd64.Open) but not 8. If we can add RHEL 8 directly (or perhaps another RHEL rebuild like CentoS 8 was?), we can probably do without an explicit CentOS 8 leg.
• Fedora 34 is itself EOL: https://docs.fedoraproject.org/en-US/releases/eol/. We will remove that at some point soon too, right? Besides, RHEL 8 was, roughly, a fork from Fedora 28. There's enough changes between Fedora 28 and 34 that I wouldn't trust test result from 34 to tell me what the compatibility situation with 28 is.
• CentOS Stream 8 tracks the upcoming version of RHEL 8. It's probably easier to think of it as"this will be in the next update of RHEL 8" as in "when users run dnf update in about 6 months, this is what they will get". That wouldn't be a major version upgrade. There won't be any API or ABI change in major components or core libraries. Generally speaking, breaking changes would not be allowed. This isn't an update to RHEL 9. So I wouldn't expect any breakage here and the maintenance work should be little-to-none. If we see any issues, we have time to fix it as a bug in RHEL and/or update .NET to handle that before it starts affecting folks using RHEL (or a rebuild) in production.

In other words, we should add RHEL 8, or a RHEL-8-rebuild in our CI matrix. If not, CentOS Stream 8 shouldn't be too bad.

This may work great for live systems but it seems like this is going to be more tricky with container rebuilds and manual updates in runtime.

I am not sure I follow this. Could you elaborate?

[wfurt]

This may work great for live systems but it seems like this is going to be more tricky with container rebuilds and manual updates in runtime.

I am not sure I follow this. Could you elaborate?

To me the "Stream" implies continuous changes. I don't really know if there was something else besides the naming e.g. the motivation to kill Centos 8 and Centos 9. It feels like we update our images rarely so they may not reject current reality. I only find this because I was trying to add msquic to Centos 8 we use and realized it os gone.

To the test coverage: We can probably add something to extra-platforms if risk is reasonable. I don't think the goal is to test every release. For example we test Ubuntu 18 & 22 e.g. oldest and latest as spot-check hoping all in-between would work as well. When convenient we may switch versions for different architectures to get more spread coverage.

I'm wondering if it would be better to use Centos Stream 9 to test the latest versions. If you feel Centos Stream 8 is the right choice I'm fine with that. It would be great if RH can contribute and maintain docker image.

Since Centos 8 is dead I'm inclined to take this change and perhaps start new issue/discussion how to maximize test coverage without adding (too many) new runs.