[CentOS-devel] [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/

Hi,

There have already been plenty of responses to yesterday's announcement. 
Still I wanted to express my opinion about this change, but not just 
simply say that it is bad and complain about it. After all it is what we 
probably have to deal with. So please excuse me that my response is 
longer than most others so far.
Disclaimer: I honestly haven't read all of the previous posts as many of 
them are quite similar. Hence some of the topics/issues I'll mentioned 
have probably already been mentioned previously.

Background (as I haven't really been active on this mailing list 
previously, just skip if you don't care):
I'm working for a small group of physicists at a university in Germany. 
As part-time work we are running and maintaining several systems, 
including storage systems (glusterfs) and what people tend to refer to 
as "HPC". All these systems are currently running CentOS Linux 7 
(x86_64) or 8 (aarch64 and x86_64).
Relying solely on public funds all our work shall be public as well. For 
software this simply means Open Source everything. Hence our budget for 
software is 0.
Still this does not mean we simply want to get everything for free: We 
try to get involved in open source projects as far as possible. The 
experiences vary substantially depending on the upstream management. 
With Red Hat they have been good so far.


The announcement of discontinuing CentOS Linux 8 and solely focusing on 
CentOS Stream was shocking at first, however after thinking about it, we 
might actually switch to CentOS Stream. We already cherry pick changes 
from CentOS Stream to fix bugs in CentOS Linux now instead of waiting 
for the next RHEL minor release. Hence the switch to CentOS Stream might 
actually not be that big, but the consequences for required 3rd party 
software might be. This has been the reason why we chose CentOS in the 
first place: It is supported by any/most hardware vendors (Intel, 
nVidia, AMD, Mellanox, Fujitsu, etc.).

With RHEL now being developed more in public (due to the availability of 
CentOS Stream) I expect that the time between Red Hat releasing a new 
major/minor release and the hardware vendor officially supporting it 
shrinks. Which is obviously good. However I doubt CentOS Stream users 
will benefit at all. Yes, hardware vendors might use CentOS Stream 
internally to verify their software will work with the next minor 
release early on, but I doubt that they will release software updates 
for CentOS Stream or even officially support it. From a QA perspective 
supporting CentOS Stream is a nightmare and simply impossible to do: You 
can never guarantee that you fully support CentOS Stream as it might 
change and break stuff the moment you publish your software. If at all 
you could say you support CentOS Stream as of "YYYY-MM-DD xx:xx:xx UTC". 
Which would mean that I have to have a local copy of any CentOS Stream 
release. And in case of relying on multiple 3rd party software packages 
it gets almost impossible as the chances of all choosing the exact same 
timestamp are very unlikely. Hence I expect no official support for 
CentOS Stream by any hardware vendor. Still I expect that for most the 
software released for the latest RHEL minor release will simply work as 
is (e.g. AMD ROCm and nVidia CUDA) most of the time. For other hardware 
vendors that have been bad at even supporting recent RHEL minor 
releases, I don't expect any changes and you might simply be out of 
luck. E.g., in our particular case, Fujitsu who are still only 
supporting RHEL 8.1. However this is already an issue nowadays (we 
"fixed" it by maintaining our own fork of the required code).
Still CentOS Stream (or a probably upcoming sophisticated RHEL rebuild) 
is our best shot to support all hardware we have with one OS.


A second issue is that we require packages from EPEL (already adressed 
in the FAQ), ELRepo and other 3rd party community driven repositories. 
Afaik most of these currently target RHEL and not CentOS (e.g. EPEL and 
ELRepo). The packages just work on CentOS Linux as well due to it simply 
being a rebuild. This is not the case for CentOS Stream. However, these 
being open source community driven projects, we all can get involved 
there to fix this issue by adding CentOS Stream as a target OS.

In case of ELRepo it might be a good idea to use DKMS instead of kABI 
kmod for CentOS Stream. I know that the kABI is supposed to be 
consistent for a major EL release, and hence understand why ELRepo uses 
kABI-tracking kmod packages. However experience has shown that this is 
not always true. Some packages have to be rebuilt for a new minor 
release. CentOS Stream being a rolling release you never know when a 
rebuild is required and there is no way to have seperate repositories 
for the "old" and "new" version as you simply can't specify what is 
"old" and "new".
Hence I already have a first proposal now to consider:
Add DKMS to CentOS Stream. With CentOS Stream being a rolling release it 
makes sense to support DKMS. Currently this is, afaik, part of EPEL.


Just my opinion about this announced change to CentOS.
Once the devel repository for CentOS Stream is populated (currently 
empty) and Storage SIG (glusterfs) builds are available (currently they 
just point to CentOS Linux 8 packages, which probably work fine) I'll 
give it a try.


Thanks for reading and have a nice day!

Peter


On 08/12/2020 15.06, Rich Bowen wrote:
> The future of the CentOS Project is CentOS Stream, and over the next 
> year we’ll be shifting focus from CentOS Linux, the rebuild of Red Hat 
> Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a 
> current RHEL release. CentOS Linux 8, as a rebuild of RHEL 8, will end 
> at the end of 2021. CentOS Stream continues after that date, serving as 
> the upstream (development) branch of Red Hat Enterprise Linux.
> 
> Meanwhile, we understand many of you are deeply invested in CentOS Linux 
> 7, and we’ll continue to produce that version through the remainder of 
> the RHEL 7 life cycle. 
> https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates
> 
> CentOS Stream will also be the centerpiece of a major shift in 
> collaboration among the CentOS Special Interest Groups (SIGs). This 
> ensures SIGs are developing and testing against what becomes the next 
> version of RHEL. This also provides SIGs a clear single goal, rather 
> than having to build and test for two releases. It gives the CentOS 
> contributor community a great deal of influence in the future of RHEL. 
> And it removes confusion around what “CentOS” means in the Linux 
> distribution ecosystem.
> 
> When CentOS Linux 8 (the rebuild of RHEL8) ends, your best option will 
> be to migrate to CentOS Stream 8, which is a small delta from CentOS 
> Linux 8, and has regular updates like traditional CentOS Linux releases. 
> If you are using CentOS Linux 8 in a production environment, and are 
> concerned that CentOS Stream will not meet your needs, we encourage you 
> to contact Red Hat about options.
> 
> We have an FAQ - https://centos.org/distro-faq/ - to help with your 
> information and planning needs, as you figure out how this shift of 
> project focus might affect you.
> 
> [See also: Red Hat's perspective on this. 
> https://www.redhat.com/en/blog/centos-stream-building-innovative-future-enterprise-linux] 
> 
> 
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos