[RFC] Making things easier when working with custom products & Simple Content Access (SCA)

[gvde]

Well, this is continuing from Deprecation of legacy subscription management:

@jeremylenz

When changing this for a given repository, it would affect all hosts which have access to that repository, immediately. There’s no way to make it affect “just new products” or “just hosts registered after this,” etc. This is why we had to revert that change originally in 2020.

I still think, giving access to the enable setting for each repository would be useful. For the potential “side effects” of the current setting of a repository, I would see two simple solutions:

1. show a warning explaining why this is “dangerous” and the side effects. The user could then simply solve this by setting up the necessary overrides on all hosts (very easy via bulk operation) and activation keys (easy, but requires changes of all/many activation keys because there is no bulk operation for keys).

2. You could silently set the necessary overrides to keep the the current state, i.e. override the repo status on all hosts and keys, i.e. after the change of the default the repository has an override on all hosts and keys.

1 + 2 could be combined, i.e. warning the user and given the option to set the overrides. As additional option, the user could choose the remove the overrides where it’s already set to the new default, which would clean up a lot for me if you are using SCA and thus have already tons of disabled overrides for all the custom product repos we have.

As a practical example: let’s say I change the default for my postgresql14-el8 repository from the current (only possible) enabled to disabled.

The operation shows a warning: “if you change this it will disable the repository for all hosts and activation keys which have access to this repository and don’t have an enabled override”

Offer the option to override any host and any activation key, which does not have an override for this repository set, yet, to override enabled, thus maintaining enabled postgresql14-el8 repos at those places which don’t have it enabled by manual override already.

Also offer the option to remove any disabled override from any host and any activation key, which currently have an explicit disabled override for this repository, removing the manual override and thus reverting to the new default disable. (This would remove all those overrides I had to set after I have switched to SCA).

With the first option or both hosts and keys still have the same enabled repository set.

@jeremylenz

It would be giving users yet another configuration option. We’ve been given the directive “don’t add any more of those.”

I would find that rather frustrating that only RHEL products should be able enable/disable a reasonable set by default. If I use any operating system, it’s reasonable to have some repositories like BaseOS, AppStream enabled and others like extras, powertools, disabled just like it’s for RHEL.

And for some products, I occasionally have to make testing/debug/development repos available for select hosts in addition to the production repos. Again, it would be extremely useful, if the production repo would be enabled by default and the others are disabled by default.

I mean, the option is there in the database for a reason. Because it’s necessary. Because some people at redhat put some thought into to what should be enabled by default and what not. I want to do the same for the products and repositories I use.

Because in the end, you have to do this anyway: all existing installations without SCA need a working migration to the new model, otherwise they’ll end up with all there hosts having access to lots of repositories which they didn’t have before.

And it can’t really be the idea of deprecating subscriptions management only for people requiring to rebuilt subscriptions using content views for all combinations of products used.