Chapter 4. Upgrading from Previous Versions
The following sections describe how to upgrade from previous major or minor versions to the most current supported version of OpenShift Enterprise using the
ose-upgrade tool. If you are deploying OpenShift Enterprise for the first time, see Section 6.3, “Using the Sample Deployment Steps” for installation instructions. If you are attempting to apply the latest errata within a minor release of OpenShift Enterprise 2 (for example, updating from release 2.1.6 to 2.1.8), see Chapter 15, Asynchronous Errata Updates for specific update instructions.
Upgrades across major or minor versions must be taken one upgrade at a time. For example, to upgrade from 2.0 to 2.2, you must first use the
ose-upgrade tool to upgrade from 2.0 to 2.1, then use the tool again to upgrade from 2.1 to 2.2.
These upgrade processes require outages:
- Broker services are disabled during the upgrade.
- Applications are unavailable during certain steps of the upgrade. During the outage, users can still access their gears using
SSH, but should be advised against performing any Git pushes. See the section on your relevant upgrade path for more specific outage information. - Although it may not be necessary, Red Hat recommends rebooting all hosts after an upgrade. Due to the scheduled outage, this is a good time to apply any kernel updates that are included.
The updated OpenShift Enterprise packages are distributed in new channel repositories on Red Hat Network so that the upgrade process occurs in a prescribed order, and to avoid accidental upgrades with a
yum update command.
4.1. Upgrade Tool
The upgrade process is managed as a series of steps that vary depending on the type of host, and is guided by the
ose-upgrade tool.
- Each step typically consists of one or more scripts to be executed and varies depending on the type of host.
- Upgrade steps and scripts must be executed in a given order, and are tracked by the
ose-upgradetool. The upgrade tool tracks all steps that have been executed and those that have failed. The next step or script is not executed when a previous one has failed. - Failed steps can be reattempted after the issues are resolved. Note that only scripts that previously failed are executed again, so ensure you are aware of the impact and that the issue has been resolved correctly. If necessary, use the
--skipoption to mark a step complete and proceed to the next step. However, only do this when absolutely required. - The
ose-upgradetool log file is stored at/var/log/openshift/upgrade.logfor review if required.
At any time, use the
ose-upgrade status command to list the known steps and view the next step that must be performed. Performing all the steps without pausing with the ose-upgrade all command is only recommended for node hosts. For broker hosts, Red Hat recommends that you pause after each step to better understand the process, and understand the next step to be performed.
