Is there any rollback feature available in foreman/katello?

Now that I know how to push content to clients with katello, I have another question. Is there any way to roll back systems after applying updates?

For example, with yum, we can use yum downgrade or undo the transaction with transaction id. But when using something like katello, is there any similar feature available that can perform similar task?

FWIW, in spacewalk (open source version of Red Hat satellite 5), there is a feature called ‘snapshot tag’, by which you can create a snapshot tag of the system and if there is any problem after patching (let’s say hard dependency on some package due to an application), you can rollback to that snapshot tag. Of course kernel, selinux, glibc don’t come under this category, but for other packages this works. Is any similar feature available in katello that I may have missed in documentation?

If not, do you think such a feature request has possiblity to be included?


Hi, there is no such a feature at the moment, but there definitely was a demand for it. I’m not aware of recent plans on that though, perhaps somebody from @katello will know better.

I’m not sure if this fits your use case or you are already doing this, but you can manage content with content view versions and associate your content hosts with lifecycle environments. Then you can promote and manage each content view version for each lifecycle environment to manage what content that host sees.

Hi John,

I am using content view with versioning but I haven’t tested whether I can move the content host from version 2 to version 1. Also I am not sure of the consequences of such a downgrade, will the system show any issues with broken dependency, or something of that sort…I don’t know.

But I can try this on my lab. I will test and report back. Thanks for answering.

Hey @enoerror,

as mentioned by John you’d need to present the system with the older version of the ContentView. However, this will not downgrade the system automatically, you still have to do this yourself with yum distro-sync or similar. I would not expect any dependency issues (as the old CV version was useable before you upgraded to v2), however you might encounter packages that don’t downgrade cleanly (e.g. because they change on-disk data after the upgrade, and the older version is not able to read the new data).

So, as usual, YMMV and please test it in your environment :wink:


What he is looking for is snapshot feature, using CV version for 1 for host1 and using CV version 2 for host to is not easy, as yoh need to create 2 different CVs and map to each host.

If my CV version 2 is in prod lc env then some prod hosts can not attache to CV version 1, with snapshot may be its possible to revert changes to earlier state without chaning CV for that host.