Deprecation of legacy subscription management

I am not sure if you really understood what I have meant.

I don’t want to change any current defaults. The current defaults can remain as they are. I just want - at a minimum - be able to set the default enable flag on any new repository I add. Currently, whenever I add a new repository to my katello server with SCA, that repository is enabled for all hosts and all activation keys (and wherever else repository sets might be used). I would like to see that it’s possible to set the default flag to disabled meaning the new repository is disabled by default for all hosts and activation keys.

As I wrote before, add a warning message for users, if they change the default flag on an existing repository because it may have unexpected side effects. But that’s only for changing existing repositories.

For a new repository the current policy enabled can have serious side effects while default disabled wouldn’t make any change to hosts and keys.

It’s not about a feature making legacy subscription management easier. It’s a feature which makes SCA easier or in my opinion, actually usable. Without being able to set the default for a new repository it’s a major hassle in a SCA system to add a new repository. I have just added centos stream 9 and el9 repos for foreman client and postgresql and then I had again to immediately modify all my hosts and activation keys to set up overrides to disabled for all those new repositories.

With legacy subscriptions it was easier, because only repositories of subscribed products where listed at all, i.e. if I added our postgresql product to a host I only had to disable all postgresql repositories except the one I want.

With SCA I have to disable any new postgresql repository I add in the future on all hosts and activation keys.

So to be clear: adding an option to set/change the default flag for repositories is not about legacy subscription but in my opinion to make SCA usable at all.

I don’t think so. For me it doesn’t change anything except maybe that I could mimic subscriptions with individual content views (i.e. I create one content view per product…).

The basic problem remains the same: you add a new repository to your product. You add the repository to a content view. Publish and promote. Now all hosts set for this content view have this new repository enabled by default.

As I wrote before: I am pretty sure that in 99,9% of the cases that’s not what uses want. Whenever, I add a new repository to my system, I want that repository disabled everywhere and only enable it on specific hosts. I don’t want to disable it on all hosts expect the ones which need it…

1 Like

yeah, you’re right, that would be more about making SCA easier rather than making non-SCA easier.

Thanks for outlining your concerns here. Know that they are definitely having an impact and please keep the comments coming :slight_smile:

Hi,
Yesterday I tried to work with Simple Content Access it caused me issues.
Red hat servers tried to install package from rocky repository & centos 7 and redhat 7.9.
I hope before the finale deprecation someone will solve this issue.

Hi,
just to want point out that I am facing the exact same problem as @gvde. When foreman 3.0 was installed first time in our company not having this feature ( Configure default repository set for subscriptions) in SCA was actually the reason to not using SCA at all. And now I am worried that there is no possiblity to turn Simple Content Access off in katello >=4.6.

@gvde how do you cope with new repos when adding them to an existing product postgresql?
Assumption: postgresql product contains 5 repositories with postgresql 9-14
Problem: Each Server subscribing this product would, after adding a new repo, have the new repo enabled by default since activation-keys are effectively working only on initial assignment.
my current Solution: Initially override each servers “enabled” setting for the new repo to disabled via hammer-cli. This is the only way to get a clean setup as we would expect. Afterwards everyone can pickup opt-in whether to eanable this repo.

Not having this feature mentioned would end up in a big problem in terms of how we have our CVs and CCVs structured. This would mean to completely restructure how CVs and CCVs are currently desinged.

1 Like

I handled it the primitive way:

  1. Go through all activation keys and disable the new repository there.
  2. Select all content hosts and use the “Manage Repository Sets” to disable it on all content hosts.
  3. Add it to the content views where needed.

This seems to be the only SCA safe way to do it with official means.

Hacking the flag in the candlepin database might be the alternative, although I don’t know if that is safe to do…

2 Likes

One ugly way is to basically create one product for each version of postgresql in leziri example. Having the same problem when adding new repos with new versions to my MariaDB product, servers keep getting a higher version of the MariaDB enabled without me wanting it. Have to be super careful to not end up upgrading a DB to an unwanted version.

Which won’t help anymore once SCA becomes mandatory.

Maybe I did not understand SCA properly then, Going to the subscription page in Foreman does not give me a warning and on this page is all my custom products. So basically product = subscription.
So if I add a new product, no host will subscribed to that automatically.

If you don’t see a warning on the subscription page, you might be using an older version of Foreman / Katello? That banner has been there for a while… (Or, you have SCA turned on already.)

Just to clarify one thing: You’ll still be able to opt out of SCA in Katello >= 4.6 and probably a few versions after. Non-SCA mode is deprecated but that doesn’t mean it’s going away tomorrow.

There is no warning before Katello 4.5. I have only noticed it with 4.5 (see original post above).

Correct. As long as you don’t use SCA, you assign subscriptions (aka products) to content hosts and they get access to all repositories in the product. As you cannot set the default for repositories in products to disabled, a content host has all repositories of your custom products enabled by default. (Of course you can hide repositories with content views and you can use activation keys to set most repositories to disabled for new content hosts…)

Once SCA becomes mandatory, there are no subscriptions anymore. Content hosts connected to your server have access to all repositories (visible in the assigned content view), which again are enabled by default for all repositories in all your custom products.

Still, it needs preparation because otherwise your client hosts all of a sudden will have tons of repositories visible and enabled after the change…

On Katello 4.5.1.
Simple Content Access is not really something I had to select when installing and am not a Red Hat customer and have not imported a manifest and looking in the documentation it says,

Simple Content Access

Note: Currently this feature is only relevant for Red Hat customers who import subscription manifests, but will be available to all Katello users in a future version.

Looking in setttings:

So I assume I do not use SCA but I do not get a warning about it.
Maybe that is why I am a little confused about this topic :slight_smile:

I think you’ve discovered a bug, thanks!

The deprecation banner currently shows only if a manifest is imported. But now that SCA status is no longer coupled to the manifest, it should show regardless.

Filed Bug #35698: SCA deprecation banners don't show if manifest not imported - Katello - Foreman.

I am still a little confused. According to gvde the banner say:

This organization is not using Simple Content Access. Legacy subscription management is deprecated and will be removed in a future version.

So this tells me you can either use “Simple Content Access” or “Subscription management”.
“Simple Content Access” is only for Red Hat customers who import subscription manifests so not for me.
“Subscription management” will according to the banner be deprecated and I guess that is what I am using?
So since SCA is not for me and “Subscription management” will be removed in the future, what is left?

RedHat is deprecating subscription management and switching to SCA. That‘s why satellite/katello is, too.

You can use SCA. Just right know, there is the GUI option missing to activate it, unless you have imported a manifest. Once that bug mentioned has been solved, you‘ll have the option to use SCA. And at some point in the future, you‘ll have to use it, once subscription management has been removed…

If you upgrade to Katello 4.6 you will be able to turn SCA on or off without importing a manifest. It’s on the Organization edit screen.

just to add my experience to it:

  • enabled SCA
  • all 63 repos became active on all hosts (including el6+7+8+9 simultaniously)
  • as soon as you did an update vm switched to el9 glibc on el8 hosts, ssh stopped working on all hosts, you are esstially locked out and theres no way to rollback anymore

i feel “simple” content access does not live up its name

Yes. That is well known and discussed. See also [RFC] Making things easier when working with custom products & Simple Content Access (SCA)

I have still not taken the plunge to SCA, but seems when Katello 4.8.1 arrives and deployed is the time to do it I guess. :sunglasses:

Seen 4.8.1 arrive but nothing in release notes about actually solving the problem with all repos activated when going to SCA.

Alas, being a minor release 4.8.1 didn’t get anything added to the “Headline features” documentation section. This particular change is kind of special that way; we don’t usually add features in patch releases.

Rest assured, Fixes #36301 - Auto-create content overrides on SCA enable (#10528) · Katello/katello@6f25812 · GitHub is indeed in 4.8.1 - Commits · Katello/katello · GitHub

@lfu I think perhaps the 4.8.1 branch needs to have its CHANGELOG.md updated?