For custom products and repositories the default status is always “Enabled”. There is no way to set this when adding a new repository nor is there any way to change it.
This means if you want to add a new repository but don’t want it enabled by default on all clients accessing the product/subscription, you have to manually set an override on all clients as well as on all activation keys.
Currently, only with the manifest for RedHat subscriptions this information is delivered, which is why the baseos repository is enabled by default and the optional is not.
IMHO, it is absolutely necessary to have an option to set the default mode for a repository in a product before SCA becomes mandatory. Because otherwise, with SCA it means that whenever I add a new repository to katello (e.g. the latest foreman client repository) and put it into my content views but don’t want to deploy it, yet, I immediately must set an override on all client hosts and activation keys to prevent the repository to become visible and enabled on all clients once my content view gets published and promoted. (If you are running against the library it’s immediate of course).
I encountered the issue with repos being enabled by default. My solution has been to have a product per version, instead of everything under one product. That way I can have multiple repositories in a content view, and essentially filter out what is accessible to the host via subscriptions, and not deal with enable/disable repositories when adding new ones.
The downside is that I can no longer enable/disable repositories from the client itself, I will have to re-register with different/updated activation key to adjust the subscriptions.
If I am understanding this correctly, then my method will no longer work and I am back to the same problem? I would love to see the ability to set disable by default when creating new repositories.
There are currently two ways to address the problem of “I’m using SCA, so I no longer can control access to content by not attaching subscriptions”:
a) repository enablement / disablement via overrides in Repository Sets, either on activation keys or on individual hosts
b) Restrict to OS Version and Restrict to Architecture features on individual custom repositories. This only works on RHEL hosts because of technical reasons related to entitlement and product certificates.
Red Hat customers who use RHEL have access to both of these tools, but upstream users only have access to a).
Disabling repositories by default has been discussed internally at Red Hat extensively. But this is probably not going to happen because of the way that Candlepin works-- essentially if the default were switched to disable custom products by default, this would apply to all hosts and not just existing ones, and my understanding is there isn’t a straightforward way to selectively disable repos in this way. Some users may be fine with disabling custom products retroactively for all hosts, but others may be significantly disrupted by it. So it’s something that Red Hat has decided not to do.
If anyone has any suggestions on how we can make this easier to manage for upstream users (without custom product default enablement changing) I would welcome them.
I don’t think you understand the problem: I don’t suggest to change the default from enabled to disabled, but to allow users to set the default for a repository.
Currently, all repositories are enabled by default, except for the RedHat repository which are all disabled by default except for base/appstream repos.
As far as I understand, this default settings is a simple setting in the candlepin database:
candlepin=# \d cp2_product_content
Table "public.cp2_product_content"
Column | Type | Collation | Nullable | Default
--------------+--------------------------+-----------+----------+---------
product_uuid | character varying(32) | | not null |
content_uuid | character varying(32) | | not null |
enabled | boolean | | |
created | timestamp with time zone | | |
updated | timestamp with time zone | | |
id | character varying(32) | | not null |
Indexes:
"cp2_product_content_pk" PRIMARY KEY, btree (id)
Foreign-key constraints:
"cp2_product_content_fk1" FOREIGN KEY (product_uuid) REFERENCES cp2_products(uuid) ON DELETE CASCADE
"cp2_product_content_fk2" FOREIGN KEY (content_uuid) REFERENCES cp2_content(uuid) ON DELETE CASCADE
This enabled flag is shown on the product content tab for each subscription in the ui.
All I am suggesting is to give users access to this flag, i.e. give users the option to set it. I know it changes everything if you modify the flag later, but it would be a good start to have this option and to set it for any new product.
The default for this option in a new repository then could be ‘false’. All repositories which already exist get the ‘true’ from the current setting in the database anyway.
That would be needed to evaluated very carefully, because that’s also exactly the problem users will face once you switch to SCA. There also no straightforward way to selectively disable repos for people who don’t all of a sudden have all their hosts access all repositories of all products in the content view.
For me switching to SCA would mean that I have to set disable overrides on all repositories of all products to which a client wasn’t subscribed to before. A simple CentOS 7 host in our setup has 6 repositories from 5 products enabled by default. With SCA all of a sudden there would be approx. 130 more repositories showing up, which I have to disable. That’s a mess.
So even hard disabling repositories like you have described would sound better to me than the other way, because in that case I only would have to set enable overrides for a few repositories, which were enabled before.
(Kind of the same issue I have now with my migration of foreman to a new server and setting everything up via the foreman ansible modules, because the ansible modules don’t allow you to set the repository set on the server, i.e. I probably write a script, which dumps the labels of all enabled repositories on the client, then connects the client to the new server, then setting disable overrides on all repositories and afterwards enabling those dumped before…)
So, ideally, you should give people a migration tool which does the SCA migration maintaining the same enabled/disable repositories. In that process, it would be no problem changing the default on the existing repositories to disable if people want it.
And the default “disabled” seems absolutely reasonable, anyway, because don’t forget: when every you add a repository to an existing or new product, I have to remember to set it to disabled on all existing hosts as well as on all activation keys. That’s what it is now and with SCA it’s just much worse. And that’s just completely counter-intuitive. If I add a new repository, I want to enable on the few clients which need it and not disable it on all my clients and activation keys which don’t need it.
For RedHat it’s easier to decide not to do this, because they can control which repositories are enabled by default and which not and for their repositories the default is disabled.
I strongly think the enabled flag must become a configurable option for users. Just saying, custom repositories are enabled by default is cumbersome and short-sighted, in particular, considering the RedHat itself applies basically the opposite polices for their own repositories.
And there should be a migration tool which reconfigures the system to SCA, making sure that all enabled repositories of all existing clients and all activation keys remain the same.
I am terrible at Python, but I know my SQL and seeing what’s in the database and with some reverse engineering I might try to make the migration in the database.
Otherwise, I would have to write a script now, which loops through all client hosts, determines all the custom products it’s not subscribed to, then loop through all those products and override all repositories in those products to disabled.
But again: the whole idea of having everything enabled by default and you have to disable everything which you don’t need is counter-productive. Why do I have to disable ~130 repositories not needed on all my clients instead of enabling the few repos they actually use?
I will leave that to the Candlepin experts to address. But one question: why aren’t content views solving this problem? Why must it be on the product or repository level?
Because I have hundreds of clients using different sets of products, using different sets of repositories. In the end I would have hundreds of content views…
For instance, we provide the postgresql repositories. Different clients use different versions. Some are el7 some el8. We only have content views for el7 and el8. That’s pretty much it. With the current legacy subscriptions we even have CentOS Stream 8, Alma 8, and RHEL 8 in the same content view, as it’s much simpler.
@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
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…
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.
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.
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.
