@jeremylenz For custom products & content, Candlepin doesn’t care. It is just passing along the values that it is given during the creation of those products. If katello wanted to disabled by default or specified by the user when a custom product is created or updated that would be perfectly fine.
I recently also talked about how great it would be, if we could set a default disabled property in Katello 
(or use the restrict by os / arch for something different than RHEL)
In my case I’m also not really using a bigger amount of CVs rather than one or two for all (using them for content filtering), and due to that I’m disabling the repos on the one hand during the bootstrap via the Activation Key, and later it’s a manual task when adding a subscription by disabling each individual unneeded repo on every host.
For me it’s not RHEL but Rocky Linux mostly, but it doesn’t really change the use in the Katello UI.
e.g. Remi’s RPM repo has 3 repos but only the safe and module stream repo are mostly needed,
or when switching to a new major version (including different repo) is needed.
Finally for me the UI already suggests that it should be possible to set repos to disabled by default,
as on the host repository config page it tells us the state is either default (enabled) or the 2 overrides with enabled or disabled
Would be very much appreciated if this feature would appear sometime in the future
@jeremylenz I am worried that this thread will also just be forgotten and in weeks or months from now just the same topic will pop up again. My redmine issue Feature #31510: Configure default repository set for subscriptions - Katello - Foreman is stored on backlog and I suspect it will never be considered because it mentions “subscription”.
It would be good if this makes some progress and there will be a solution, soon. Because it’s really annoying. On my new soon-to-be-production server with 4.5 I have enabled SCA and whenever I add a repository I have to be extremely cautions to set overrides to disable everywhere: on all my activation keys as well as on all hosts. Because honestly: I think 99,9% of the cases I want any new repository being disabled by default.
I don’t expect candlepin to work differently. All I really want is being able to change that flag in the candlepin database which defines the default for this repository. Simply another checkbox added to the UI of a repository to set/change the default setting. Add a warning if people change the flag later on to tell them about potential consequences. Default for new repositories should be disabled, probably.
Give the users access to the default enabled flag.
I really think with SCA it is really necessary because nothing is worse then exposing new repositories to hosts by default which shouldn’t have them… And I don’t think this has to do with candlepin but with katello and changing something in candlepin. The functionality itself seems to be there already.
You’re right that the reason this feature isn’t there is not because it’s not possible or feasible. Rather, it’s because it was determined (by higher-up people who are not me) that it would cause too much user confusion and upset. Any time you change the defaults, you’re always going to upset someone. And the fact that it’s going away eventually means that putting effort into designing features that make legacy subscription management easier no longer makes a lot of sense. It’s pretty much been decided as a rule that we will not address bugs or feature requests in this area unless they break something major. I know it’s frustrating but please be assured that we will do everything we can to make SCA the best experience it can be-- because it’s the future.
This should also help quite a bit: We’re in the early planning stages for Katello to support Candlepin’s new multi-environment feature. This means that you’ll be able to assign hosts to multiple content views. We expect this feature to be available well before legacy subscription management goes away.
Restrict by OS only works with RHEL due to technical limitations, but we are also looking at making Restrict by Arch work with non-RHEL OSes.
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 
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:
- Go through all activation keys and disable the new repository there.
- Select all content hosts and use the “Manage Repository Sets” to disable it on all content hosts.
- 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 
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.