I think this will affect the project.
I think it at least means we should revisit Feedback Wanted: The Installation Paths we Support as a Project.
There are several aspects we should probably investigate:
Our own installation. Only the time will show, how CentOS Stream will be stable and I do believe it will be as rock solid as current CentOS (media compare the switch to Arch Linux while this is not the case). There are few things we can do to improve confidence of our own users: locking packages via
foreman-maintain, self-subscription to make sure updates are under better control or simply accelerating containers deployment. These come to my mind as random thoughts. Of course, we are currently on RHEL7/CentOS7 and there is no change in this regard, this is rather longer-term goal.
Better Katello integration. We will probably see more users looking into content management pretty soon. We need to make sure Katello deployments are great, documentation and installation are better than ever. I think more focus on improving docs to lower the initial confusion about relationship between Foreman and Katello would be a good start, probably some articles on our blog or somewhere else how to leverage Katello both for CentOS Stream and Debian/Ubuntu.
New subscriptions. Red Hat announced there will be a new program with free and low-cost subscriptions. As a project, we need to make sure we are ready from the day one so the experience is smooth. There is nothing we can do at this point as the details are not available, but if there is anything you know about that could be improved for Katello workflows to simplify and improve the experience, let’s talk about it.
Errata management. Once CentOS Stream is adopted in the wild, I think the current lack of dnf errata integration on CentOS is a huge gap between RHEL and CentOS. There are some scripts out there that do provide some integration for Spacewalk and Katello, this could be an opportunity to fill the gap if this was a native feature. ATIX has already a solution for Debian as there is a similar problem, having this in the project for both major OSes with the very same user experience would be huge.
Provisioning. We need to verify that provisioning with CentOS Stream works as usual - no surprises. I’ve heard that something does not work at the moment, I will be looking into this part pretty soon I guess.
I think there are other areas I am missing, these just come to my mind.
Definitely Packaging is a thing with big changes. At the moment we use CentOS to build packages for all RHEL derivates. I think the RHEL Universal Build Image was not enough for packaging, so perhaps we need a subscription to build RHEL packages in the future, because CentOS will not be the same base and we have more package versions to build to be compatible to CentOS and RHEL.
This could then lead to Puppet Modules which need to be adjusted to handle CentOS differently.
What makes you think CentOS Stream is changing this? For packaging we use Koji which keeps buildroot under full control. Koji can either consume upstream repository (downloading packages each build) or use a mirror of our own. We use both to optimize money (storing many GBs is expensive on Amazon).
In the worst case, we will probably need to start mirroring CentOS base repository, if we are not doing that today (I am not sure, I think we do). So CentOS Stream is not changing anything in this regard, for buildroots it’s usually the best approach to use older y-releases. With RHEL there is an advantage we can choose any y-release (8.0, 8.1), with CentOS Stream I assume there will be some base version to start with and this one can be used as upstream for our buildroots.
Other than that, I don’t see any changes. CentOS Stream is only changing pace of incoming updates which won’t affect us.
As a rolling release I would assume CentOS Stream being ahead of RHEL, also not as much as Fedora, and no longer being binary compatible. With ruby (as a base for most things we need) it is no problem in the best case, but in the worst case we have a newer version of ruby we want to use on CentOS Stream but it is not seen as stable enough to be included in RHEL yet. In this case we would need handle both differently.
Or infrastructural things can differ like SELinux policy or something like nftable hitting earlier on CentOS.
Of course this will be good as we can test and adjust earlier, but on the other side it could mean more work.
No actually, this confusion is everywhere unfortunately due to poor communication of the change. CentOS Stream will only contain updates which were carefully cherry-picked by RHEL product managers and verified by Red Hat QA. Technically, the only difference is that CentOS users will be getting the updates before RHEL users. There are no expected changes in quality, if there is a new bug (a regression) introduced into RHEL, CentOS users also get it today, just few days later. But they get it, it takes some time before Red Hat is able to deliver a fix (unless it’s some kind of high-importance security problem). Users who care about their systems should do proper patch management even today, CentOS Stream does not change anything about it.