My apologies for my walls of text, but I feel I have not yet been as clear as I could be. This morning I went over the UI together with @Bernhard_Suttner and we came to a consensus on what we think the best possible solution is (given what already exists within Katello). It combines his “Transparent CV” concept with some of my suggestions for the backend implementation. I will try to describe this latest state of deliberations as clearly as I can.
Background on how the status quo works:
Before I can start I need to describe the status quo of how the “Default Organization View” works:
When a user creates a new repository within some product, Katello creates a Katello::RootRepository
record as well as a Katello::Repository
record, that is referred to as “the Library instance of this repository”. The latter references a newly created Pulp repository and Pulp distribution. You can look at the Pulp publication in your browser by following the “Published At” link from the Katello repository UI page. When you sync some content to the Katello repository, This is synced into the existing Pulp repo, a new Pulp publication is created from the result, and the existing Pulp distribution is updated with the new publication. If you now follow the “Published At” link you will see the new content. The published at URL is structured as follows: https://<your_instance>/pulp/content/<org>/Library/custom/<product>/<repo>/
. It always serves your latest synced state.
When you tell a host to use “Library” + “Default Organization View” as its content source, the host will consume that very same “Published At” URL that you can see on the repository page. The very same Pulp repo that Katello asks Pulp to sync content into, which means you automatically always get the latest synced state. In Katello terminology, the host is consuming the “Library instance repository, associated with the given root repository”.
The “Library” environment for a normal CV (not the “Default Organization View”) is very different. It requires you to create a CV version, which will then automatically be promoted to “Library”. Under the hood this creates two extra Katello::Repository
records (one for the CV version, and one for the CV-Library environment combination), which are in turn associated with newly created Pulp entities. The CV version repository record gets a new Pulp repository and content is then copied from the “library instance” Pulp repository to that new Pulp repo (CV filters are applied as part of the copy action). Katello will also have Pulp create a new Pulp publication and Pulp distribution from the new repo. The CV-Library repository record does not get new Pulp entities, instead it is associated with the same Pulp entities as the CV version repository. The difference is that the version repository will never have those Pulp associations updated again (it represents a frozen content state), while the Library repo will be updated if Library is later promoted to a different CV version. Hosts ultimately consume the Pulp repo referenced by the CV-Library Katello repository instance.
Terminology: I find it useful to distinguish between “latest-Library” which is the Library environment as used by the “Default Organization View”, and “CV-Library” which is the Library environment as used for a normal CV.
The use case:
Some users like using “latest-Library”, because it is simple, new syncs are immediately available to hosts, and they do not care about the ability to roll back to old CV versions, apply filters, etc.
The problem:
Currently the only way to use “latest-Library” is via the “Default Organization View”. However, the “Default Organization View” automatically contains all the repositories that exist in Katello. Before SCA it was possible to limit this via the subscriptions available to some host. With SCA this is no longer possible. Users can still disable any repos they do not care about, but that still leads to significant irritation for users that have content for multiple different OSes and OS versions in Katello. It simply does not make sense to configure my “Alma Linux 8” repos on my “Rocky Linux 7” hosts even if they are correctly disabled. On SLES, various zypper list commands will list all the irrelevant disabled repositories by default. Depending on how many OSes and OS versions I have I might have hundreds of disabled repositories along with the 5 enabled repositories I actually want.
The proposal:
Let’s have a “transparent CV”, that can be associated with arbitrary Katello repositories (user choice) just like a normal CV. Unlike a normal CV, the transparent CV does not have any Versions, Filters, or History and is only ever available in the “Library” environment, just like the “Default Organization View”. Unlike the “Default Organization View” hosts using “Library” with some transparent CV, only get the repositories that are in the transparent CV. Just like with the “Default Organization View”, hosts will consume the Pulp distribution that is linked to from the Katello repository page via the “Published At” URL.
This has the enormous advantage, that no new Pulp repositories are ever needed for a transparent CV, avoiding the expensive operation of copying content from one Pulp repo to another. In fact, no new Katello or Pulp entities of any kind are needed. The only new entities that are needed, are some candlepin entities whenever a new transparent CV is created, or has a repository added or removed to it by the user. The candlepin content for the singel root repository associated with any given Katello repository already exists, and does not need to be created. Each transparent CV needs to create a single Candlepin Environment (different from a Katello Environment) when it is first created. Whenever a repository is added to a transparent CV by the user, the relevant candlepin content needs to be added to the relevant candlepin environment. When a repo is removed, the candlepin content needs to be removed from the candlepin environment. That should be it.
The necessary UI changes are also pretty minimal. The CV creation box needs to list a third possible type (“Transparent CV”). Once created a transparent CV looks exactly like a normal CV, except that the Versions, Filters, and History tabs, as well as the “Publish new version” button is missing. There are no new Katello environments, since Transparent CVs will use “Library” just like the “Default Organization View” uses “Library”. When creating an Activation Key, or changing the content source on a content host, the only thing that has changed, is that once a user selects “Library” for the environment, the drop down list of CVs will include any transparent CVs that exist.
We think this makes for a very clean design, that does not add any additional complexity to existing CVs or CCVs, and creates a bare minimum of new entities.
Note: Once this proposal is implemented, the “Default Organization View” would be functionally equivalent to a transparent CV, that the user has added all repositories to.