We are currently running Foreman 1.16 and Katello 3.5. I am looking at patching the Katello application and wanted to check that the process I have in mind won’t break our setup.
We have the Katello host registered to itself and its Content View has our base CentOS 7 repos along with EPEL 7, Foreman 1.16 and Katello 3.5 repos. All of these are synced with their upstream sources weekly.
The plan is to treat this as any other application patching, publish and promote a new version of the Content View then patch the server using yum. Is this safe to do?
As this is not an upgrade and the server only has access to Foreman and Katello packages within it’s current major version my thinking is that using foreman-installer for this is not required.
We do not currently have Katello Agent installed on the Katello host, are there any issues with doing so?
Apologies if this seems pretty simple, I’d rather ask a silly question and be sure than fix a broken install.
If you adhere to the upgrade documentation (which is essentially what you’re doing right?), you have to stop all katello services prior to running a yum update which means your yum repositories won’t be available.
With that in mind, I’d suggest your katello server doesn’t register to itself as a content host and looks directly at the upstream source.
I’m interested to see how anyone else has tackled this procedure though…
I’m not sure that I’d call this process an upgrade. You might start with Katello 3.5.0 and Foreman 1.16.0 and end up with Katello 3.5.2 and Foreman 1.16.2 but you’d still have the same feature set. I’m thinking of this more as a patching process where you update the OS and applications via yum then reboot the server. In that use case I think the Katello host could get Katello application patches from itself. What I’m looking for is reasons why it shouldn’t. If the Katello services need to be stopped prior to being patched that would be one, and make the whole question moot for the reasons you’ve given.
This is definitely what we’d do for upgrades, say from 3.5 to 3.6. Disable any local Katello Content Views, add the upstream Katello repos holding the version we wish to upgrade to and conduct the upgrade as per the documentation.
I’m not sure you can differentiate between an upgrade and patching. The process is the same for both and depending on the packages being updated will cause issues if applied to a running katello instance (in my experience at least).
Some of the rpms run rake tasks for example as part of the install/update procedure which will hang indefinitely on a running katello instance.
This could have been a specific behaviour for a specific upgrade for specific versions but it’s definitely driven our process away from trying to patch a katello server using itself a content host…
If that’s the kind of behaviour you have seen then I’d agree that having the Katello host subscribed to itself for Katello packages is not advisable, even for packages within the same major version. Thanks for pointing it out.
With that information in mind we will treat Katello application “patching” and “upgrades” the same and source the required packages from their upstream source.
For what it’s worth: that’s also why Red Hat’s product based on Katello doesn’t support self hosting. The upgrade process is rather tied together. I guess that in theory you could download all packages, then stop the services to do the upgrade but so far nobody has spent time to make sure this works.
I also agree that patching and upgrades are the same. The only difference is the amount of code that changes, but the process is the same.
That said, we always welcome more contributions in this area. Smooth upgrades are critical for users. I’d be happy to point people in the right direction if they have questions.
