Problem:
I made a new Content View, which is composed from multiple Products (repositories).
When I assign the Content View to hosts, the hosts will consistently show that some of the repositories are disabled.
Expected outcome:
I could override (enable) all disabled repositories on each host, but I want to enable them on the global level (in the Content View).
I don’t understand where a repository could be enabled or disabled in the Content View.
Not sure if the problem is me not understanding Content Views, or the Foreman?
Custom repositories are always disabled by default. However, they can be overridden to enabled as you’ve done. When you override a repository to enabled, it’s called a “content override.”
Content overrides can be per-host as you’ve shown here. You can also add them on an activation key, so that any hosts registered with that activation key will have the repositories enabled. Content overrides don’t exist for a content view; rather, you have to override either on a host or an activation key.
An activation key could assign your hosts both a content view and content overrides. This is the way I would recommend setting it up. Also keep in mind, activation keys only affect hosts at registration time, so if you make changes to an activation key, the hosts registered with that AK won’t change unless you re-register them with the same AK.
Many thanks Jeremy!
It’s a good explanation, and I understand what you are saying.
But I struggle understand why this is so.
I am creating Content Views, because I want to assign Repositories to remote hosts, with the intention that these hosts will be able to use the software provided by these repositories.
Why would anyone want to assign Content Views that are disabled? That’s pointless.
And it turns out that non-Red Hat distros are discriminated compared to Red Hat distros. Is there a good technical reason behind it?
Long story short, there are plenty of situations where you want to restrict hosts’ access to content, and there are plenty of situations where you want to allow it. And some where you want to allow some content, and disallow others, and have it all be in the same content view. I’m sure some other users on this forum can give examples. With content overrides, this is all quite customizable, and it was determined that disabled is the best default for custom products in the context of SCA.
Oranization is managing large number of hosts (e.g. 1000)
Administrator decides to change the Content View for all hosts
All hosts receive new Content View in an automated manner, resulting in all custom repositories being disabled
Administrator would have to enable all repositories on all hosts - individually
And furthermore, there is the problem that an inexperienced administrator may not even notice that all software repositories were accidentally disabled by the change of Content Views. There is no warning.
OK, you may say that the new Content View should have its own dedicated Activation Key, and under the Activation Key, the Administrator may override-enable custom repositories.
However, that would mean that every Content View should have its corresponding Activation Key, which is
not in the spirit of Activation Keys, but rather a workaround
not intuitive
tedious to maintain and overly complicated
I suggest the following enhancements:
When changing Content Views, administrators should be warned that custom repos will be disabled
In the “All Hosts” list, every host with disabled repositories should receive a one-off warning event (amber exclamation mark), which, once confirmed, will disappear.
Content Views should provide a flag that can override the default behavior on the level of Content View - Custom repos disabled/enabled
Ability to mass change “Enable all disabled repos” on selected hosts
Content views and content overrides are completely unrelated. For example, let’s say you have Contentview1 which has Repo1 and Contentview2 which has Repo2. Let’s say your host is first assigned to Contentview1. You can add content overrides to the host for both Repo1 and Repo2 (even though the host doesn’t have access to Repo2 thru its content view.) Then when you switch the host’s content view to Contentview2, the override will already be in place for Repo2.
You can use multiple activation keys when registering. This means that ak1 can assign the host a content view, while ak2 adds content overrides. (These content overrides may cover any repositories, not just those in a particular content view.) You can then use both ak1 and ak2 when registering, and the host will get the content view and content overrides.
If you do need to make a bulk change to host content overrides without re-registering hosts, you can do so in the web UI: Hosts > Content Hosts > (select multiple hosts) > Select Action > Manage Repository Sets. If you have the hosts in a Host Collection, you can also do this from the Host Collection details page.
