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-upgrade tool. 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 --skip option to mark a step complete and proceed to the next step. However, only do this when absolutely required.
  • The ose-upgrade tool log file is stored at /var/log/openshift/upgrade.log for 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.