-
Language:
English
-
Language:
English
4.4. Upgrading from OpenShift Enterprise 2.0 to OpenShift Enterprise 2.1
begin
step, adjusts the yum
configurations in preparation for the upgrade. Red Hat recommends that you perform this step in advance of the scheduled outage to ensure any subscription issues are resolved before you proceed with the upgrade.
Procedure 4.16. To Bootstrap the Upgrade and Perform the begin
Step:
- The openshift-enterprise-release RPM package includes the
ose-upgrade
tool that guides you through the upgrade process. Install the openshift-enterprise-release package on each host, and update it to the most current version.#
yum install openshift-enterprise-release
- The
begin
step of the upgrade process applies to all hosts, and includes those hosts that contain only supporting services such as MongoDB and ActiveMQ. Hosts using Red Hat Subscription Management (RHSM) or Red Hat Network (RHN) Classic are unsubscribed from the 2.0 channels and subscribed to the new 2.1 channels.Warning
This step assumes that the channel names come directly from Red Hat Network. If the package source is an instance of Red Hat Satellite or Subscription Asset Manager and the channel names are remapped differently, you must change this yourself. Examine the scripts in the/usr/lib/ruby/site_ruby/1.8/ose-upgrade/host/upgrades/3/
directory for use as models. You can also add your custom script to a subdirectory to be executed with theose-upgrade
tool.In addition to updating the channel set, modifications to theyum
configuration give priority to the OpenShift Enterprise, Red Hat Enterprise Linux, and JBoss repositories. However, packages from other sources are excluded as required to prevent certain issues with dependency management that occur between the various channels.Run thebegin
step on each host. Note that the command output is different depending on the type of host. The following example output is from a broker host:#
ose-upgrade begin
INFO: OpenShift broker installed. INFO: Setting host step 'begin' status to UPGRADING INFO: Starting upgrade number 3 to version 2.1. [...] INFO: updating /etc/openshift-enterprise-release INFO: Setting host step 'begin' status to COMPLETE INFO: To continue the upgrade, install a specific upgrade package.Important
Theoo-admin-yum-validator --oo-version 2.1 --fix-all
command is run automatically during thebegin
step. When using RHN Classic, the command does not automatically subscribe a system to the OpenShift Enterprise 2.1 channels, but instead reports the manual steps required. After the channels are manually subscribed, running thebegin
step again sets the properyum
priorities and continues as expected.
Procedure 4.17. To Install the Upgrade RPM Specific to a Host:
- Depending on the host type, install the latest upgrade RPM package from the new OpenShift Enterprise 2.1 channels. For broker hosts, install the openshift-enterprise-upgrade-broker package:
#
yum install openshift-enterprise-upgrade-broker
For node hosts, install the openshift-enterprise-upgrade-node package:#
yum install openshift-enterprise-upgrade-node
If the package is already installed because of a previous upgrade, it still must be updated to the latest package version for the OpenShift Enterprise 2.1 upgrade. - The
ose-upgrade
tool guides the upgrade process by listing the necessary steps that are specific to the upgrade scenario, and identifies the step to be performed next. Theose-upgrade status
command, orose-upgrade
, provides a current status report. The command output varies depending on the type of host. The following example output is from a broker host:#
ose-upgrade status
INFO: OpenShift broker installed. Current upgrade is number 3 to version 2.1. Step sequence: begin pre outage rpms conf maintenance_mode pending_ops confirm_nodes data gears end_maintenance_mode post Next step is: pre
Procedure 4.18. To Perform the pre
Step on Broker and Node Hosts:
- The
pre
step manages the following actions:- Backs up OpenShift Enterprise configuration files.
- Clears pending operations older than one hour. (Broker hosts only)
- Performs any pre-upgrade datastore migration steps. (Broker hosts only)
Run thepre
step on one broker host and each node host:#
ose-upgrade pre
When one broker host begins this step, any attempts made by other broker hosts to run thepre
step simultaneously will fail. - After the
pre
step completes on the first broker host, run it on any remaining broker hosts.
Procedure 4.19. To Perform the outage
Step on Broker and Node Hosts:
- The
outage
step stops services as required depending on the type of host.Warning
The broker enters outage mode during this upgrade step. A substantial outage also begins for applications on the node hosts. Scaled applications are unable to contact any child gears during the outage. These outages last until theend_maintenance_mode
step is complete.Perform this step on all broker hosts first, and then on all node hosts. This begins the broker outage, and all communication between the broker host and the node hosts is stopped. Perform theoutage
step with the following command:#
ose-upgrade outage
After the command completes on all hosts, node and broker hosts can be upgraded simultaneously until the upgrade steps are complete on all node hosts, and the broker host reaches theconfirm_nodes
step. - For all other hosts that are not a broker or a node host, run
yum update
to upgrade any services that are installed, such as MongoDB or ActiveMQ:#
yum update
Procedure 4.20. To Perform the rpms
Step on Broker and Node Hosts:
- The
rpms
step updates RPM packages installed on the host, and installs any new RPM packages that are required. For node hosts, this includes the recommended cartridge dependency metapackages for any cartridge already installed on a node. See Section 9.8.3, “Installing Cartridge Dependency Metapackages” for more information about cartridge dependency metapackages.Run therpms
step on each host:#
ose-upgrade rpms
Procedure 4.21. To Perform the conf
Step on Broker and Node Hosts:
- The
conf
step changes the OpenShift Enterprise configuration to match the new codebase installed in the previous step. Each modified file is first copied to a file with the same name plus a.ugsave
extension and a timestamp. This makes it easier to determine what files have changed.Run theconf
step on each host:#
ose-upgrade conf
Warning
If the configuration files have been significantly modified from the recommended configuration, manual intervention may be required to merge configuration changes so that they can be used with OpenShift Enterprise.
Procedure 4.22. To Perform the maintenance_mode
Step on Broker and Node Hosts:
- The
maintenance_mode
step manages the following actions:- Configures the broker to disable the API and return an outage notification to any requests. (Broker hosts only)
- Starts the broker service and, if installed, the console service in maintenance mode so that they provide clients with an outage notification. (Broker hosts only)
- Clears the broker and console caches. (Broker hosts only)
- Enables gear upgrade extensions. (Node hosts only)
- Saves and regenerates configurations for any
apache-vhost
front ends. (Node hosts only) - Stops the
openshift-iptables-port-proxy
service. (Node hosts only) - Starts the
ruby193-mcollective
service. (Node hosts only)
Run themaintenance_mode
step on each host:#
ose-upgrade maintenance_mode
Procedure 4.23. To Perform the pending_ops
Step on Broker Hosts:
- The
pending_ops
step clears records of any pending application operations because the outage prevents them from ever completing. Run thepending_ops
step on one broker host only:#
ose-upgrade pending_ops
- On any remaining broker hosts, run the following command to skip the
pending_ops
step:#
ose-upgrade pending_ops --skip
Procedure 4.24. To Perform the confirm_nodes
Step on Broker Hosts:
- The
confirm_nodes
step attempts to access all known node hosts to determine whether they have all been upgraded before proceeding. This step fails if themaintenance_mode
step has not been completed on all node hosts, or if MCollective cannot access any node hosts.Run theconfirm_nodes
step on a broker host:#
ose-upgrade confirm_nodes
- If this step fails due to node hosts that are no longer deployed, you may need to skip the
confirm_nodes
step. Ensure that all node hosts reported missing are not actually expected to respond, then skip theconfirm_nodes
step with the following command:#
ose-upgrade --skip confirm_nodes
Procedure 4.25. To Perform the data
Step on Broker Hosts:
- The
data
step runs a data migration against the shared broker datastore. Run thedata
step on one broker host:#
ose-upgrade data
When one broker host begins this step, any attempts made by other broker hosts to run thedata
step simultaneously will fail. - After the
data
step completes on the first broker host, run it on any remaining broker hosts.
Procedure 4.26. To Perform the gears
Step on Broker Hosts:
- The
gears
step runs a gear migration through the required changes so that they can be used in OpenShift Enterprise 2.1. Run thegears
step on one broker host:#
ose-upgrade gears
When one broker host begins this step, any attempts made by other broker hosts to run thegears
step simultaneously will fail. - After the
gears
step completes on the first broker host, run it on any remaining broker hosts.
Procedure 4.27. To Perform the test_gears_complete
Step on Node Hosts:
- The
test_gears_complete
step verifies the gear migrations are complete before proceeding. This step blocks the upgrade on node hosts by waiting until thegears
step has completed on an associated broker host. Run thetest_gears_complete
step on all node hosts:#
ose-upgrade test_gears_complete
Procedure 4.28. To Perform the end_maintenance_mode
Step on Broker and Node Hosts:
- The
end_maintenance_mode
step starts the services that were stopped in themaintenance_mode
step or added in the interim. It gracefully restartshttpd
to complete the node host upgrade, and restarts the broker service and, if installed, the console service. Complete this step on all node hosts first before running it on the broker hosts:#
ose-upgrade end_maintenance_mode
- Run the
oo-accept-node
script on each node host to verify that it is correctly configured:#
oo-accept-node
Procedure 4.29. To Perform the post
Step on Broker Hosts:
- The
post
step manages the following actions on the broker host:- Imports cartridges to the datastore.
- Performs any post-upgrade datastore migration steps.
- Clears the broker and console caches.
Run thepost
step on a broker host:#
ose-upgrade post
When one broker host begins this step, any attempts made by other broker hosts to run thepost
step simultaneously will fail. - After the
post
step completes on the first broker host, run it on any remaining broker hosts. - The upgrade is now complete for an OpenShift Enterprise installation. Run
oo-diagnostics
on each host to diagnose any problems:#
oo-diagnostics
Although the goal is to make the upgrade process as easy as possible, some known issues must be addressed manually:
- Because Jenkins applications cannot be migrated, follow these steps to regain functionality:
- Save any modifications made to existing Jenkins jobs.
- Remove the existing Jenkins application.
- Add the Jenkins application again.
- Add the Jenkins client cartridge as required.
- Reapply the required modifications from the first step.
- There are no notifications when a gear is successfully migrated but fails to start. This may not be a migration failure because there may be multiple reasons why a gear fails to start. However, Red Hat recommends that you verify the operation of your applications after upgrading. The
service openshift-gears status
command may be helpful in certain situations.