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
This will likely be my final update on this thread.
The PR has had some review and is nearing completion.
However, we plan to merge it only after Katello 4.16 has branched (mid February).
As a result, the feature should finally land in Katello 4.17.
4 Likes
Proposal: Enhancing Rolling Content View (RCV) Lifecycle Environment Promotion in Katello
Background
Currently, Rolling Content Views (RCVs) in Katello are always associated with the Library environment. This presents a challenge when consuming a specific RCV, as users must sync Library to a Smart Proxy, which is often undesirable in real-world deployments.
Proposed Enhancement
We propose adding an option in Rolling Content Views to allow automatic promotion to a different Lifecycle Environment (LE) instead of—or in addition to—Library.
Key Features
- A new setting in RCV to define target Lifecycle Environment(s).
- Users can choose one or multiple LCEs as the promotion target.
Benefits
More flexibility in content distribution.
Reduces the need to sync Library to Smart Proxy.
What are your thoughts?
Does this feature in general make sense?
If yes, would you expect to have additional to Library or instead of the promotion to Library?
Possibility to select only one LCE or multiple LCEs?
3 Likes
From a user perspective, it makes sense not to have rolling content views restricted to Library, so you can sync them to smart proxies without syncing Library to those smart proxies.
My main concern is around the “lightweightness” of Rolling content views compared to regular content views.
Does this mean that a promoted rolling content view will have to have content copied somewhere by Pulp? What are the implications there?
If it’s a Candlepin-only change, e.g. “just create a content view environment with a different name and we don’t have to do any additional content-shuffling with Pulp” then that’d be ideal. But I have a feeling it’s somewhere in between.
1 Like
I am a +1 on this because syncing Library is an overhead for smart proxies. But this seems like a more generic feature of allowing automated CV promotes…There have been discussions around doing this for all CVs with something like a sync plan for example…If we are doing automated promotes on these CVs, I’d love a solution which extends to publish as well and reusable for all CVs instead of being limited to rolling CVs. Does that make sense?
1 Like
I would hope this would not be the case, rather that the rolling CV gets attached a simple LCE label? It would then ‘only’ change where the rolling CV is distributed by Pulp, how it gets synced to the smart proxy, and how clients consume it.
I agree that this is the most important part.
My hope would be that this would be even simpler than ‘promotion’ as we know it today since content view versions aren’t involved. It would be more like adding a label (or labels plural?) to the rolling CV
Generally I think the idea of using LCEs with rolling content views is logically sound. It fits with what users would expect. The only thing that is a little confusing is that, while LCEs can be attached, there is no “lifecycle management” with rolling CVs – no snapshots to hold on to. So the lifecycle environment is logically just being used as a label.
I think that concept is okay, especially because the fact that lifecycle environments are treated so specially is something that confuses new users anyway. In hindsight I wish they could have just been simple labels from the start.
1 Like
A picture is beginning to emerge in my mind. What if
A new, “special” LCE is created, called Rolling
It would be created (and/or visible to the user) automatically once you have at least one rolling CV
You cannot alter or delete it
You cannot add it as a prior env or create lifecycle environment paths with it
You can sync it to smart proxies just like any other LCE
New rolling CVs would automatically live both in Library and Rolling LCEs
Thoughts? (Still not sure about the Pulp side of things here).
2 Likes
I like this approach, if we go with this approach, we def want to make sure we are covered on the hammer/api side and not add those validations in the UI. We have been burned on that before with other features.