Content Management: Combined versioning with non versioning

Hello folks

I have two questions concerning content management. I think I understood the concept of the different components like cv or products provided by katello. A cv allows to version current states of repositories and push them through a lifecycle. If I don’t want versioning, I can simply point an activation key to the “Library Environment” and the “Default Organization View”. This leads to having always the latest repository content available on subscriber side.

I got both scenarios working on different clients. Everything fine so far. But now, I would like to achieve a combination of both. Let’s take the example of a GitLab server:

  • I don’t want to version the OS Repositories and have always the latest packages available on the clients without having to release new cv versions on every maintenance window.
  • For GitLab packages, I want to have versioning in place and test new releases before having them available on production systems.

I created a a graphic to show my idea:

Is this possible? Until now, I haven’t found a solution for this idea. Or do you think it is even a bad idea?

This leads me into my second question. I have a content view - lets say again for the gitlab repository. During the the synchronization a new gitlab-ce package version is downloaded. Does this new package appear as installable update on the content host view or do I have to publish a new cv version to see, that there is a new version available?


While I would not recommend it, it is achievable by publishing the repositories without certificate-based authentication required which means by HTTP for now. Then you could manually configure the repositories instead of using the subscription-manager and by this losing the content host functionality at least partially.

And for your second question: Installable means it is readily available in a repository assigned to the host, applicable can be configured in the settings if it takes library or the assigned content view into account.


One point of clarification, with katello 4.0+ if you turn on http for a repository, it will work without any client certificates even with https. (This is a change with pulp3). We need to update the UI to better indicate this, but the api parameter is called ‘unprotected’ and better indicates the state. If its set to false, a client cert is required, if its set to true its not. In both cases its accessible via http & https (but since its not possible to pass a client cert via http, if unprotected is set to false, it essentially turns http access off)

1 Like