-
Language:
English
-
Language:
English
4.5. Upgrading from OpenShift Enterprise 2.1 to OpenShift Enterprise 2.2
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.30. 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.1 channels and subscribed to the new 2.2 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/4/
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 4 to version 2.2. [...] 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.2 --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.2 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.31. 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.2 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.2 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 4 to version 2.2. 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.32. 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. - After the
pre
step completes on all hosts, theose-upgrade
tool allows you to continue through the node and broker host upgrade steps in parallel. On broker hosts, the tool will block theconfirm_nodes
step if the associated node hosts have not completed theirmaintenance_mode
step. On node hosts, the tool blocks thetest_gears_complete
step if the associated broker has not completed thegears
step.Continue through the following procedures for instructions on each subsequent step.
Procedure 4.33. 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
- 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.34. 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.This step also disables the SSLv3 protocol on each broker host in favor of TLS due to CVE-2014-3566.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.35. To Perform the maintenance_mode
Step on Broker and Node Hosts:
Warning
end_maintenance_mode
step is complete.
- Starting with OpenShift Enterprise 2.2, the
apache-mod-rewrite
front-end server proxy plug-in is deprecated. New deployments of OpenShift Enterprise 2.2 now use theapache-vhost
plug-in as the default.Important
Any new nodes added to your deployment after the upgrade will use theapache-vhost
plug-in by default. Note that theapache-mod-rewrite
plug-in is incompatible with theapache-vhost
plug-in, and the front-end server configuration on all nodes across a deployment must be consistent. See Section 10.1, “Front-End Server Proxies” for more information.The default behavior of themaintenance_mode
step is to leave theapache-mod-rewrite
plug-in in place, if it is installed. Do not set theOSE_UPGRADE_MIGRATE_VHOST
environment variable at all, not even tofalse
or0
, if you require this default behavior.However, if your OpenShift Enterprise 2.1 deployment was configured to use theapache-mod-rewrite
plug-in before starting the 2.2 upgrade, you can optionally allow theose-upgrade
tool to migrate your node hosts to the newly-defaultapache-vhost
plug-in. To enable this option, set theOSE_UPGRADE_MIGRATE_VHOST
environment variable on each node host:# export OSE_UPGRADE_MIGRATE_VHOST=true
- The
maintenance_mode
step manages actions in the following order:- Configures the broker to disable the API and return an outage notification to any requests. (Broker hosts only)
- Restarts 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)
- Stops the
ruby193-mcollective
service. (Node hosts only) - Saves the front-end server proxy configuration. (Node hosts only)
- If the
OSE_UPGRADE_MIGRATE_VHOST
environment variable was set in the previous step, migrates from theapache-mod-rewrite
plug-in to theapache-vhost
plug-in. (Node hosts only) - Disables the SSLv3 protocol in favor of TLS due to CVE-2014-3566. (Node hosts only)
- Enables gear upgrade extensions. (Node hosts only)
- Starts the
ruby193-mcollective
service. (Node hosts only)
Run themaintenance_mode
step on each host:#
ose-upgrade maintenance_mode
Procedure 4.36. 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:#
ose-upgrade pending_ops
When one broker host begins this step, any attempts made by other broker hosts to run thepending_ops
step simultaneously will fail. - After the
pending_ops
step completes on the first broker host, run it on any remaining broker hosts.
Procedure 4.37. 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.38. 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.39. 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.2. 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.40. 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.41. To Perform the end_maintenance_mode
Step on Broker and Node Hosts:
- The
end_maintenance_mode
step restarts the following services on the node hosts:httpd
(Restarts gracefully)ruby193-mcollective
openshift-iptables-port-proxy
openshift-node-web-proxy
openshift-sni-proxy
openshift-watchman
Complete this step on all node hosts first before running it on the broker hosts:#
ose-upgrade end_maintenance_mode
- After the
end_maintenance_mode
command has completed on all node hosts, run the same command on the broker hosts to disable the outage notification enabled during the brokermaintenance_mode
step and restart the broker service and, if installed, the console service:#
ose-upgrade end_maintenance_mode
This allows the broker to respond to client requests normally again. - Run the
oo-accept-node
script on each node host to verify that it is correctly configured:#
oo-accept-node
Procedure 4.42. 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.