This is not really a technical problem, just a look and feel thing, even a very minor one. (In case you start looking for repos on a client machine via either dnf or subscription-manager, which nearly never happens)
As well very much a keeping the overview thing, a search and a filter for currently enabled repos would improve that of course, but still that is slower than just having the repos there, you enabled the subscriptions of and being able to see what is enabled or what needs to be enabled to get to the wanted result.
Correct, currently the systems get some repos disabled on the bootstrap via the Activation Key, after changing all repos to being visible to a machine all will be either enabled or disabled by default, the currently already overridden repos will stay the way they are, but the rest… Lots of manual work involved.
Or am I reading this wrong in your #3 proposal? Does it mean that all repos that previously were available but not changed to overridden disabled (so either default or enabled overridden), will be enabled overridden and everything else disabled? (looks like I didn’t think of a automatic migration then )
It wouldn’t remove the need of creating lots of CVs to keep the overview though, but at least it doesn’t have to be done while migrating to SCA, which sounds a lot better than I previously thought!
Thank you for the explanation then! And sorry for throwing the dust…
So, this means it’s basically a manual migration of subscription+CV based housekeeping to a CV-only based housekeeping, but no need for a manual host migration, which a lot less time consuming
I really should use the new UI a lot more (it’s just the bigger font that keeps me going back to the old more compact view)
I know I’m complaining on a very high level, but it’s of course more clicks
And maybe I’m very inefficient but sometimes I’m also just going through the list to enable repos like CRB without searching because, well more mouse movement and more typing.
I have created a (draft) PR to be able to use “Restrict to OS” for non-RHEL systems: Add os product tag based on /etc/os-release by sbernhard · Pull Request #3188 · candlepin/subscription-manager · GitHub Pino from candlepin team reached out to me and mentioned, that its possible to create a certificate for every candlepin product which would then be used from subscription-manager. Unfortunately, the certificate does not contain product tags which are later on used to match repository OS-tag. Maybe it would be possible to extend katello so that individual product tags can be written from katello to candlepin.
Is this really already planed and someone is working on this? I think this would be a huge mess. First, the plan was to make everything easier with SCA. Then, multiple Content Views can be assigned to a Content Host. This would also affect activation keys, APIs, etc. This would make a lot more complicated as before - and was not the idea of SCA I guess.
Thanks for the effort! Would be great to have the option to restrict it manually as not all repositories will have helpful information. As some vendors build separate packages and others only one for all different EL versions, it could also be needed to have this as some kind of array.
The certificate mentioned is the productid metadata used by the dnf/yum to have the information from which repositories/products something is actually installed and afterwards reported to Katello? Would be great to have this specified somewhere openly so other vendors can use it. Even if I think it is no solution for this problem.
To be honest this was also my first impression of the multi-CV feature-- that it would make things unnecessarily complicated. But it seems enterprise customers do have legitimate use cases for it, and it will also be a nice side bonus that it adds another option for managing custom products with SCA. That said, I’d love to hear what specific pitfalls you foresee so we can be sure to avoid them. (Allowing multi-CV registrations will be hidden behind a setting that defaults to off, so it shouldn’t affect you unless you want it.)
The repository will be enabled (Override to enable).
With the other new action to disable all repos you can first disable all repos and then enable the repos for your product using the “Activate repos from selected product” quick action
Which page would these options be on? I’m afraid I’m still not following, since repo overrides can only be set on a host or an activation key. Overrides can’t be set for all hosts.
I have the same feeling of unnecessarily complicated, but it is also quite easy for me to find a workflow were it would be helpful.
If there is a central system which needs to be updated before all of its clients like it is the case with Puppet or Icinga just to name two, then at the moment you need to workaround this. One option is to not manage the specific repository on the central system via subscription manager by an override to disable and using a repo configuration file pointing to the Library or a not promoted version. Another option you need some very special composite content views. But I see customers really having problems with this.
With the multi-CV feature, there could be a built-in solution to this. Even if it is more complicated in the end it is part of the tool and supported, so people will prefer it over a workaround and use it.
How are those multiple content views supposed to work? Does the client have multiple lifecycle environments then (one for each content view) or a single one and the client sees all content views in its lifecycle environment?
How does it handle conflicts, i.e. if the same repository is part of two or more content views? In particular, if content views contain the repository at different times with different content?
“Multiple content views” is really just a simplification. For example, here’s the way it works now, without multi-CV:
Say there are two content views, cv1 and cv2, and one LCE, Library.
Candlepin doesn’t have a concept of a thing called content views; instead, it has “environments.” Katello creates two environments in Candlepin:
cv1/Library
cv2/Library
(You can see a list of these environments from any host by running subscription-manager environments --list).
When a host is assigned to the cv2 content view in Katello, Katello tells Candlepin to assign the host’s consumer to the cv2/Library Candlepin environment.
If there are lifecycle environments in play, the idea is the same. A host assigned to, say, a cv1 content view in the “prod” environment would get the Candlepin environment called “cv1/prod.” The cv1/prod Candlepin environment contains all of the content from whatever version of cv1 has been promoted to the prod LCE.
You can view a host’s assigned environment(s) with subscription-manager environments --list-enabled.
So with the multi-CV feature, the host will be allowed to be assigned to multiple content view environments. So the CV and LCE within each respective CVE must still make sense; the difference is that Candlepin will allow the host to access content from all of its assigned content view environments instead of just one.
This is a trickier question. When a host is registered, say with subscription-manager register --environments cv1/dev,cv2/staging, I believe Candlepin looks at the order of environments passed. When assigning a host’s environment in Katello, the plan is to have a content view contain a priority value which will help decide this order.
So this means there is an idea to solve the problem of multiple versions of the same repository. But this is exactly one scenario, where it gets complicated.
We had customers, who asked why a repository did not appear but they added it to the content view. However, they forgot to add a subscription. Now they get a new feature, allowing them to have the same repository in multiple versions assigned (maybe not even intended) and they have to figure out, which has priority to identify why their hosts get newer packages, than they are supposed to? A missing repository might be something to make you unhappy to search for the cause - but to rollback a bunch of servers because one CV accidentally contained a newer version of a repository than you intended?
Besides that, the multi-CV-feature for content host will probably only have the effect, that most people stop using CCVs (where I am undecided, if this is a bad or good thing) but again it could become more complicated to have an overview which repositories in which versions are assigned to a host.
One of the biggest issues of SCA in my view is that the activation keys are less organized, because you need to enable/disable all the repositories. With multi-CV-content-host this might become less chaos per activation key but I assume then you need one activationkey per content host? For registration do I need to pass an array of activationkeys or can i just add an additional cv by just running the register command with a new key?
I know that there is already the possibiltiy to use multiple activationkeys as an array but I never needed to use it - and never tried if i always have to give the full array.
I know some customers, who will be happy about mutli-cv-content-host because they do not like the concept of ccvs. And maybe it is a nice feature - but I do not see it as a simplification or a resolution for the chaos SCA will provide to everyone not using only redhat-provided repositories.
I would prefer an approach to simplify the organization of activationkeys by having something to enable/disable a complete product and good filters and/or the possibility to restrict repositories to be only active in certain environments/OS like the restrict to os-feature, which seems to be difficult to adapt it for all OS than just RHEL.
A couple things to keep in mind here: first, the multi-CV feature is optional and off by default. So if you don’t want to deal with the complexity it adds, just leave it off. Second, the main use case for this is different categories of content being managed by different teams, wanting to move updates at different paces without updating CCVs all the time. So the case of repository conflicts will hopefully be an edge case that doesn’t happen too often.
Multi-CV won’t change how many activation keys you’ll need. When the feature is complete, you’ll be able to assign a single activation key to multiple content view environments. The rules for which activation keys apply when you pass multiple AKs will remain the same. Also keep in mind that activation keys aren’t the only way to register-- you can also register without an AK and specify the environment(s) directly. And once a system is already registered, re-registering with a different AK is not the recommended way to change a host’s content view environment or anything else; all these things can be changed easily without reregistering.
Right, of course this feature isn’t a one-shot “resolution for the chaos;” rather, it’s one additional tool in the tool bag that will hopefully make things easier for a certain subset of users.
)
(it’s just the bigger font that keeps me going back to the old more compact view)