Ok, than I probably had a wrong idea how it works. That sounds good.
Thank you for all your answers @jeremylenz
Could you maybe even answer a previous question:
Probably this is already answered with the possibility to disable all repositories by default in a new activationkey. But I ask again to make sure that the feature of the default organization view will still exist and not enable all new added repositories automatically to my hosts if I use it.
Currently, it works this way: If you have a host assigned to Default Organization View content view and Library lifecycle environment, the host will automatically get access to any newly added custom repositories since custom repos are enabled by default.
With the original proposals above, custom products would be overridden to disabled via repo sets on hosts or activation keys. So additional overrides would need to be added for newly added repositories.
With the third proposal, custom products would be disabled by default, so newly added custom repositories would be disabled unless you add overrides to enable them.
Ok thanks for the clarification - so from those options I would clearly prefer the third proposal.
Would it be possible to set a global setting if I want to default to disabled or enabled?
This would unfortunately violate the directive we’ve been given not to add any more configuration options. So we have to either decide to keep the status quo where custom products are enabled by default, or “flip it” so they’re disabled by default (proposal #3).
Made a Redmine tracker to track this work: Tracker #36179: [RFE] Improve custom products workflow when using SCA - Katello - Foreman
Pull request for this change is here: Fixes #36120 - Change default enablement for custom products by jeremylenz · Pull Request #10502 · Katello/katello · GitHub
I think to make more sense in this context, you have to mention that during the migration all existing custom repositories are also set to disabled by default then. From what you write, it only covers existing host repository overrides but not the default of the custom repository in the product.
So at the end of migration, all existing hosts will have all custom repositories overridden to enabled/disabled to present an unchanged repository set. In addition, all existing custom repositories will have their default changed from currently enabled to disabled.
New custom repositories created after that will also be disabled by default.
And I think the migration should also apply to all existing activation keys.
Yes, this is all correct, except that it only adds enabled overrides (“Override to Enabled”). Disabled overrides (“overrides to disabled”) aren’t needed because the new default enablement is already Disabled.
Yes, sort of. Now you are mixing timelines.
During migration, you only set overrides to enabled on custom repositories for each host. Because anything else should be overridden to disabled already.
After the migration, you don’t need overrides to disabled for new custom repositories as thats the default.
However, we all of it I think the one really big problems is still the same: the switch from subscriptions to simple content access.
Because with subscriptions the before scenario is more like:
Before: custom repositories are enabled by default. Let’s say with it’s current subscriptions a host has 6 custom repositories. 4 are overridden to disabled, leaving 2 repositories enabled.
But that’s only the active visible repositories with it’s current subscriptions. In fact, the host has most (likely hundreds) of the custom repositories enabled by default simply because it doesn’t have access to them due to lack of subscriptions. So the host has hundreds of repositories enabled by default and 4 overridden to disabled. But it can access only 6 of them.
If you do your migration at that time, the host will end up with hundreds of repositories enabled. And once, you have to switch to SCA because subscriptions will have been removed from katello, you’ll see all those repositories enabled.
Of course, that is essentially the same issue people face now if they switch to SCA today.
But still, I think that switch and the problem that all of a sudden you really can see all custom repositories and all of them are enabled unless already overridden is what is really important and must be dealt with. The transition from subscriptions to SCA is the really painful process.
Because for me the migration process is actually pointless: I have already switched to SCA and had to override everything else already to disabled to get the same repositories sets afterwards. In the process I have also set override to enabled to everything (actually my script did which I ran on each host and took a list of enabled repositories before the switch to SCA, and then later disabled all repositories and reenabled only those listed to be enabled before).
But I think that would be the most important part for a migration script: it should find out which custom repositories are still enabled by default but actually not accessible because of lack of subscriptions and override those to disabled as well, so that after switching to SCA they are still disabled…
The flip to disabled by default for custom products applies to all existing custom products, including those which you don’t have subscriptions for. To put it another way, both content overrides and default product enablement are things that happen regardless of subscription attachment status. So, running through this thought experiment:
Now that I type this I think I see what you’re saying. You want the products that don’t have subscriptions to get disabled overrides. I think that’s something we could think about adding in a separate issue, but would add a lot of complication here. This migration is about upgrading to Katello 4.9, not switching to SCA.
We had already planned on adding a similar rake task that you can run yourself (as opposed to automatically during upgrade) to freeze repo enablement. I think this work is coming more into focus now, and we can see if it’s feasible to have that task look at existing subscriptions.
Yes. And that’s exactly what I am concerned about. You set overrides to custom repositories which are enabled by default but actually not visible to the client host because lack of subscription.
Let’s say I have a product postgresql with various postgresql repositories.
And I have a client host which has not been subscribed to the postgresql product ever. Thus, unless I specifically set overrides for the repositories of the postgresql product (IIRC it is possible to so even if not subscribed), by default the client host will net set any override for any postgresql repository and thus all those postgresql repositories are enabled by default (because it doesn’t an override). The client cannot see the repositories and they are not in redhat.repo because it’s not subscribed. But technically, because of the lack of override they are enabled by default.
Thus, if you now run the migration without regard of subscriptions, you would override all those postgresql repositories to be enabled by override.
But that means, if you switch to SCA (without running an upgrade/migration script) the client host all of a sudden would have access to all custom repositories of all products it was not subscribed before because all those repositories have been overridden to be enabled.
But this step is actually the painful step when switching to SCA: whether everything is currently enabled by default or with your migration later enabled by override: without preparation and some scripting all your clients all of a sudden have all custom repositories enabled for which it didn’t have a subscription before. Which in my case meant they had more than a hundred additional repositories enabled… Content views somewhat mitigated that but still, for instance, all my clients which didn’t used postgresql before had all postgresql repositories enabled…
I cannot oversee how much effort this will take in the future to handle that in a separate issue. My concern here is a little bit the loss of information you have the moment you set overrides. Because your migration effectively means that after the migration all client hosts will have overrides for all custom repositories: either the override (enable or disable) was in place before or you override it during the migration to be enabled. After the migration any existing client will have an override for any existing custom repository.
So you’ll loose the information what was enabled by default and what was enabled by override. Before you had three states for a repository-host relation: default, enabled, disabled. Now you only have two. I am not sure if that’s a problem down the road when you are switching to SCA. Maybe not, but if you remove some information even if it seems redundant at the moment I am always a little bit worried if this may cause problems for some.
I think it could play a role in cases where there are meaningful overrides set to a host for custom repositories of a product it is currently not subscribed to but has been in the past. But maybe I am overthinking this…
You’re right that this new subscription-aware rake task would add overrides for any non-subscribed products, and would overwrite any existing overrides. But my assumption is that (a) a user wouldn’t add any such overrides themselves, because why would that make any sense? and so (b) any existing overrides for non-subscribed products would be the ones added automatically by Fixes #36120 - Change default enablement for custom products by jeremylenz · Pull Request #10502 · Katello/katello · GitHub.
There may be some instances where the (a) assumption is incorrect, as you say, but I think that will be rare enough that it shouldn’t be an issue to fix manually – a lot easier than fixing all of your custom repos manually!
It would actually be ideal if this subscription-aware rake task could run before the upgrade task. This way the disabled overrides would already be in place, so the upgrade task wouldn’t touch them. I’m looking into that.
This has been a very long discussion, and I’m sorry if I have missed it up-thread. But one thing that would make this feature set a lot easier to manage is if the content_label for a specific repo in a specific content view were easier to get at. The “label” is available easily enough, but “content_label” (which is needed for specifying overrides for activation keys) seems to be a lot harder to get at.
I would request that the full content_label be exposed at the very least on the repo page for the content view, if that is possible; and for there to be a straightforward way to derive that through the API as well (which would make it easy to get through foreman ansible modules and/or hammer, which is how I plan to use it).
If there is already a straightforward way to get this information, I would love to know how you’re doing it. It is entirely possible that I’ve missed something.
Thanks!
I mean… I’m getting them from the RootRepositories:
::Katello::RootRepository.custom.in_organization(org).map(&:custom_content_label)
But that’s only useful for developers, not users. I think it’d be a great RFE to either (a) expose the custom_content_label for each repository so you could grab it from hammer or the API; or (b) just make the /hosts/:host_id/subscriptions/content_override and /hosts/bulk/content_overrides endpoints accept repository names. Option b would be a bit more complex, though, because you’d also have to also specify an organization and product.
In any case, I’ve opened Feature #36284: Make it easier to specify the content for content overrides - Katello - Foreman
thanks!
I’m finally getting around to switching most of the stuff on my main system to a SCA ready structure (limiting with added subscriptions → limiting with CVs).
As well, here is another apologize, after thinking everything through multiple times, with the switch of disabled by default it’s really just a thing of housekeeping by creating CVs (but not explicitly needed).
It is really not as bad as I first thought!
It would be very nice to have a guidance to how best to setup the CVs in such a housekeeping case though, should it best be one CV for every OS, a CV für every OS + CVs for every application of every OS pulled together with a CCV, a CV for all OS repos + CVs for every application pulled together with a CCV, a CV for every usecase, or whatever else would work even better. I’m just very much not sure what is the best option, it’s sure getting a lot, but how much does it need to be?
I am making it ready with the first and last mentioned options right now, hopefully this will work out well 
@jeremylenz @Bernhard_Suttner I might have better directly brought the question for the state of subscription manager with SCA on Ubuntu/Debian here. So will it break my Ubuntu clients if I tick the box with 4.8?
And as you said in the Community Demo, the switch of the repos from default enabled to disabled, that affects both non-SCA and SCA (this was the part that I didn’t get there, it affects both), should be fully server side, doesn’t need any readyness of these platforms. (I really should have thought a bit more before asking that question… sorry for that as well)
Oh and how do I best run the CV publish? daily? hourly? A switch after every repo update would be nice, but will also kick of far too many CV builds, in my mind, best case there is a template for a scheduled CV publish that runs hourly/half hourly/every 10 minutes, but only when none of the affected repos are doing a sync at the moment.
I can only say from our experience and how we did it, that I have set up a CV for each OS (Alma8, Alma9, CentOS 7, CentOS Stream 8) to prevent people from accidentally installing packages from another distro or from a different major version. Other than that I only disabled all repos by default except for the standard repos. Thus, clients generally can have access to any repository we have (e.g. CentOS SIG repos, PostgreSQL, etc.) as all of those are free anyway and clients could get them directly from the public mirrors anyway.
Before SCA we had only CVs for the major version, i.e. EL7 and EL8.
CCVs don’t really work for us because they don’t follow the lifecycle of the included CVs, unless you start version pinning. So we didn’t really see any advantages to set up application CVs and put them into CCVs. There is an issue for that: Feature #30223: Lifecyle based composite content views - Katello - Foreman
That’s a very good point, I didn’t know that!
For me it was a CV for every option I needed a different filter for, meaning I had 2 CVs, one for the Zabbix Servers (puppet-agent limited), and one for everything else (puppet-agent, zabbix-agent limited).
We landed on a slightly more elegant way to do this. In Katello 4.7.5 (and the upcoming 4.8.1), turning on SCA will now automatically run a Dynflow task that creates disabled content overrides for any content for which you haven’t attached a subscription. This will prevent hosts from suddenly getting access to all custom products when SCA is turned on.
This change won’t apply to Katello 4.9+, since custom products will be disabled by default already.
If for some reason you need to turn on SCA without auto-creating overrides, you can do that with hammer:
hammer simple-content-access enable --organization-id 1 --auto-create-overrides=false
For more info, see the PR description here → https://github.com/Katello/katello/pull/10515