Bug 2211944

This is easy to be fixed, it's just about removing this line: https://github.com/rhinstaller/anaconda/blob/rhel-9/data/product.d/centos-stream.conf#L11

However, this module was explicitly forbidden by you in the past :) https://github.com/rhinstaller/anaconda/pull/2546 and I'm not 100% sure what should be the correct behavior here.

Another question is, if we are able to allow registration into the custom Foreman server without enabling Red Hat CDN registration. Martin, could you please give us insights if the SubscriptionSpoke will work on CentOS Stream or what are the expected issues?

I don't think we can really change this without a strong justification - the way its currently setup is based on the assumption that RHEL => subscription module on, not RHEL => subscription module off. This results in the module being on/off essentially also setting the subscription policy for the installer.

If the module is on, we expect that you are on RHEL & you have a RHEL subscription and you want to use it & install from the CDN. The UX is setup that way & request registration.

When the module is off, we expect that you are on Fedora or Cent OS, where you can just use a close-by mirror that does not require registration.

This is what was requested for subscription support for Anaconda on RHEL.

So if we just enabled the subscription module on Cent OS, it might start behaving like RHEL essentially, requesting the user to register. This is likely not acceptable for the majority of users that don't have their own katello server to register to. 

Unlike on RHEL, there might be the closest mirror source available in the source spoke, but I think CDN might be selected in preference to it like on RHEL. Even if it didn't, CDN would still be in the source listing, which is pretty much wrong on Cent OS & would be very confusing for users.

Another issues would be testing - already on RHEL there is a lot of combinations to test and this would be yet another scenario that would have to be tested. It would also be hard to test, as unlike with the RHEL/CDN use case, it would require custom katello instance to test against.

So overall I don't think this is really doable.

Thanks Martin for explanation and a good reasons to not go with this.

Closing this bug based on comment 2.

Weighing in on the Satellite perspective: this essentially means we will need to maintain two workflows. One for RHEL and one for Red Hat like operating systems. We're rarely, if ever, testing with RHEL in upstream due to how painful it is to access to RHEL, especially in public CI. Granted, today we don't have any automated kickstart testing

If we want to encourage customers to verify their workloads work on CentOS Stream, then it should be as close as possible to what RHEL is. Note we actually need to use the rhsm statement to work around bugs we otherwise encounter. I can't find the bug now, but if the kernel in EL 9 is newer than what's in the kickstart root then it refuses to boot afterwards. Having authenticated access to the full repositories is required when syncing content.

With that in mind, I'd urge you to reconsider this decision.

Thanks for more detailed reasoning. I completely understand your reason. 
However, as you said someone needs to do this work, do the testing and have to maintain this. As described at comment 2 by Martin for us it would be pretty painful to do so, the change but also creating tests. I honestly think that by doing this, we would gain more work than what you will reduce, which doesn't look as a good decision to me.

Sorry, but in overall we don't have any other request to support this and from the Red Hat perspective it would mean more work overall even when it's done elsewhere.