Question: can we automatically trigger the creation of a new content view version when a repo changes?

We use two lifecycle environments, Library and Production. Only Production is synced to the proxies.
A daily sync plan updates all repos, so I was wondering if it would be possible to automatically trigger a “create new version” on each relevant content view (not composite content views, as this is already handled automatically) when a repo has updated content?
As they would be only available in Library, not much is actually happening in terms of traffic to the proxies. However, I could see all new versions in the “Content View” UI and then trigger a promotion if wanted (or automatically via hammer).

As a side info: right now its not possible to see, if a repo has changed, so I would blindly create new version of content views periodically, which I think is an unnecessary hassle.

Expected outcome:
When a repo is updated and the content has changed, all content views associated with that repo are updated with a new version, promoted to Library.

Foreman and Proxy versions:

Foreman and Proxy plugin versions:

Distribution and version:
CentOS 7.9

Other relevant data:

1 Like

I would also like it if Katello (I suppose that’s the right place for this) supported an automatic promotion for non-composite content views based on whether a repository has seen any changes. Supporting this would appear to be at least partially “straightforward” because Katello knows when there is a change. A repo sync spits out the skipping Sync (no change from previous sync) when there are no new changes to sync.

I have a silly script running hammer commands to automatically promote on a nightly basis. Unfortunately, the hammer CLI commands I use do not expose any information about whether a remote repository has changed at all; so I have to assume it always has changes and promote. Perhaps I’ll have to look into whether I can grawk that particular log message from the depths of foreman’s logs to determine whether to promote a content-view or not. But it’d be much nicer if Katello just had the option to do that for me :slight_smile:

Does “library” in a content view automatically stay in sync whenever a repo is updated or does a new version have to be published in order to update a content view’s “library” env?

Another question, will accumulating a large number of content view versions cause reliability, performance or storage issues in the long run as does VM snapshots?

While this is not directly possible right now. You could make use of the last_contents_changed attribute when you make an api request (GET /katello/api/repositories/:id). Look here → Fixes #31590 - Add last changed timestamp by maccelf · Pull Request #9558 · Katello/katello · GitHub

You can use that to trigger an automatic publish/promote if contents changed on sync.

1 Like

'[quote=“gawainxl, post:3, topic:27960, full:true”]
Does “library” in a content view automatically stay in sync whenever a repo is updated or does a new version have to be published in order to update a content view’s “library” env?

If your host is registered to the Library environment and Default Content View, you do not need to publish a new version. OTOH if your host consuming from a different content view or environment you would need to publish a new version to get the latest content.

Nice. This is just what I needed (apart from being able to check a box in the CV to do it automatically).

Thank you @Partha_Aji , I will work some magic by scripting it. I still believe it would be a nice addition to Katello, just like the automatic publishing of a new version in CCV when an underlying CV changes.

Will still be a good RFE, we might could consider for the future. Please feel free to file one here → Foreman

1 Like
1 Like