Katello supports upgrades from the previous two versions only. Upgrades should be performed sequentially without skipping versions in between.
Before upgrading, run the upgrade check script that will check for any active tasks:
If Katello is running on a virtual machine, we recommend to take a snapshot prior to upgrading. Otherwise, take a backup of the relevant databases by following the instructions here.
Ensure your operating system is fully up-to-date:
Update the Foreman and Katello release packages:
Select your Operating System:
Clean the yum cache
Update the required packages:
The installer will run the right database migrations for all component services, as well as adjust the configuration to reflect what’s new in Katello 3.18.
If kernel packages are updated during Step 2 the system must be rebooted to ensure the new kernel and SELinux policy are loaded. If there are no kernel or selinux updates then this step can be omitted.
You have now successfully upgraded your Katello to 3.18.
For a rundown of what was added, please see the release notes.
If the above steps failed, please review /var/log/foreman-installer/katello.log and let us know about it if unable to resolve.
Katello 3.18 supports migrations of Content to Pulp 3 for container, yum, and file content. Depending on how much content is present, this can take a very long time. The largest part of the process can be run without downtime. This full process will need to be complete before upgrading to Katello 4.0.
Upgrading to Pulp 3 does require some additional space, although the bulk of the content is not duplicated. Ensure you have:
Due to a bug in Pulp 2.21.3 and earlier, content permissions need to be changed before migrating content. If you are fully updated to pulp-rpm-plugins-2.21.4, this only needs to be done once before migrating:
These commands can be run without outage, but may take a long time depending on the amount of content and the latency of the filesystem.
To see how much content is left to be migrated and get a time estimate, you can run:
This can be run between migrations to see how much has changed since the last migration.
Note that this is run without downtime, while content and repositories are migrated in the background. This can be run multiple times.
This will require some downtime to do the final switchover, but this will:
If you run into any issues with this process, please file a support issue with ‘[ContentMigration]’ in the subject.