Hey,
Why should we always check for the content and rpms to be added after sync plan and then publish a content view to end users?
I am expecting to have an option as the sync plan is done, and the new rpms were added, to automatically publish a new version.
I am using, Foreman server 3.10 with Katello 4.12 plugin
Publishing content views is quite expensive in terms of computation, etc., so this is not automatic. However, content view versions do have an indication when they need to be published.
cc @sajha who may have more tips here.
We do not have native support for automated CV publishes on repository syncs. The reasons range from computational cost to giving admins the control over when they choose to pull in the new content to a CV version. However, if you want this, I’d suggest creating a RFC post to gauge the community’s interest.
We do have webhook events around repo syncs which would serve your use-case: Administering Foreman
This should allow you to automate this on your end. I am hoping some of our users have a template for this and can help here.
We have a cron job running, which publishes a new content view every night and promotes them through the lifecycle environments using hammer commands.
Depending on the rest of your landscape, and the need to decide when a new publish should happen, you could also look into some Event Driven Ansible flows for that.
The Foreman webhooks docs are a little misleading, I saw this:
Anyway, the default “Katello Sync” webhook could likely fire off an API request to publish your content view.
Hey, thanks for the reply,
I am aware of the scripts, cronjobs, and hooks that can trigger and publish a CV, my meaning was, that we need to have the ability to check some “Auto publish” on the CV, not after the sync is completed, but only when new content(Rpms or errata) are being added.
Like sync status, which automates the sync based on your needs, we need to publish CV trigger based on new content.
If what you want is to always have latest synced content passed through to your hosts, you might also be interested in our “Rolling Content View” proposal: Transparent Content View for Limiting Repository-Access in Katello - #4 by sajha
Mind you we are just starting to work on that, so there is not yet a time horizon for when this might be available. The idea is to have a new type of content view, without filters or versions. Hosts consuming the content view always get the latest synced content for any repositories in the “rolling content view”, completely avoiding the overhead of publishing and promoting new content view versions (at the cost of not having filters and not being able to roll back to old versions).
I am interested in your solution.
Could you share how you implemented it?
Thanks.
It’s just a simple shell script using hammer commands:
#! /bin/bash
echo -n "Publishing and promoting... "
date
for i in 2 3 7 8 13 14 26
do
hammer content-view info --id $i --fields THIN
hammer content-view version promote --content-view-id=$i --organization ORG --from-lifecycle-environment Testing --to-lifecycle-environment Production
done
sleep 300
for i in 2 3 7 8 13 14 26
do
hammer content-view info --id $i --fields THIN
time hammer --output silent content-view publish --id $i --lifecycle-environments Testing --organization ORG
hammer --output silent content-view purge --id $i --count 1
done
date
We are using cv id numbers for brevity. The script first promotes all content-view versions from testing to production, then waits 5 minutes to let the proxy syncs finish. Then it publishes a new version, promoting it immediately to testing. Then it purges all old, unused versions except one. The scripts runs at night through a cron job, an hour after the repo syncs.
This is an important starting point, I will adjust it to my reality.
Thank you.
you should have a look at Rolling Content Views which will be available in the next katello version.
More details, see Transparent Content View for Limiting Repository-Access in Katello - #4 by sajha