For what it’s worth, “Rolling content views” is what I titled our Jira for this: https://issues.redhat.com/browse/SAT-28495
3 Likes
Interesting Topic. Wondering if this could help in our scenario also.
We have 2 kinds of repos.
- OS Repo Mirrors (Rocky9 BaseOS + Appstream + Other 3rdParty Repos)
- Our Own Packages in an extra repo
For the OS Repo Mirrors the current Content Views are perfect. We want to be able to filter them and promote them manually or on specific Events (Time Trigger, Successful Automated Tests,…)
In this case we don’t need or want access to “latest” directly even on developer machines, especially the filtering is important to us.
But now on dev machines we want to be able to access the latest from our own package repo immediately, so here the “rolling content view” would be cool to have.
Where this gets currently complicated, an activation key can only contain one lifecycle and one content view. So we can either subscribe to “library” and have access to all the latest packages, but loose control over the OS Repo Mirros since we can’t “freeze” or filter them.
Or we can subscribe to a lifecycle of a (composite) content view and have to promote a new version of our own package repo on every change (which could happen very often, like every 5-10 Minutes)
The third option would be to leave our own repo as unprotected and add it to the hosts with a repo file, but we want all of our repos protected
So it would be great if a composite view could allow to combine the new rolling view with a standard view or allow an activation key to select multiple content views from different lifecycles
It is likely that we will choose not to allow this for the initial implementation of the feature (to keep things simple so we can reach a working state as quickly as possible). Nevertheless, I will keep this idea back of mind as we work on it. Depending on what we conclude how much work this would be I could see this as a future extension of the feature.
1 Like
Good news: Activation keys will support multiple content view environments in the next Katello release (4.15). 
1 Like
Which may be a reason to say we will never support rolling content views in composite content views, because multiple content views already covers those use cases.
3 Likes
We now have an initial working state:
Unfortunately the back-end implementation required a bit more complexity than I had originally hoped, since candlepin is designed to make it impossible to have the same repo URL used in multiple candlepin environments. This necessitated creating an extra clone repo on the Katello server for each repo added to a rolling content view. During sync and upload, those clone repos need to be updated along with the library instance repo.
Even so, the new rolling content views are a lot simpler and a lot more lightweight than a regular content view with auto publish would be.
2 Likes