Upgrade and rollback

The following sections provide general information about how to do the upgrade or rollback operation. For more information about how to upgrade to a specific version of your FTM offering, see the entitled documentation fix pack for that version of the offering. The link to the entitled documentation fix pack is included in the support links for your FTM offering.

Precautions

The following list shows precautions to take when you are doing an upgrade or rollback operation.
  • Before you do the upgrade operation, you must ensure that the database backup is completed. A complete backup of the database is needed if any problems occur during the upgrade or rollback operation and you need to restore the database to its original preupgrade state.
  • During the rollback operation, the database must be restored from the database backup even if database migration was not required during the upgrade.
  • You must ensure that your FTM offering and database are at the same release version. If data needs to be migrated during the upgrade operation, the FTM offering and the database must also be upgraded. Similarly, during the rollback operation, the database must be restored to the prior version by using the backup operation.
  • Persistent volumes must be backed up to retain the data for the data migration activity.
  • Any configuration customizations must be backed up so that they can be applied after the upgrade or rollback operation.
The following additional precautions are needed for most of the FTM upgrades that you are doing.
  • You must ensure that the IBM® MQ operator is installed. For more information, see Install IBM MQ. Ensure that you have a version of Red Hat® OpenShift® Container Platform that will run the IBM MQ operator installed in your cluster. For more information about whether you need to install the IBM MQ operator, see FTM Hardware and Software requirements.

Upgrade

During the upgrade operation, you must quiesce the application by scaling the application pods down to zero. To scale the deployment down to zero, change the operator disaster recovery mode parameter to passive. After you scale down the pods, you must complete the following migration activities.
  • If release updates have database schema changes, run the data migration activities.
  • If changes are done to the persistent volumes or to the directory structure that is used by the pods, migrate the persistent volumes. The working directories, test fix files, or the user exit JAR files must be identified and migrated to the new location.

After the migration activities are completed, start the application pods for the new release by setting the operator disaster recovery mode to active and then scaling up the pods. If the customization strategy was changed or if new config maps were introduced for customization, you must migrate the configuration customization files.

Rollback

During the rollback operation, you must quiesce the application by scaling the application pods down to zero. To scale the deployment down to zero, change the operator disaster recovery mode parameter to passive. After you scale down the pods, you must complete the following restoration activities before you upgrade.
  • The database must be restored from the backup taken.
  • The persistent volume directories must be restored from the backup taken.
  • The customer configuration files from the config maps must be restored from the backup that was taken before the upgrade. If new config maps were created by the operator, the configuration must be restored after the application pods are up.

After the migration activities are completed, start the application pods for the previous release by setting the operator disaster recovery mode back to active and by scaling up the pods.

FTM versioning

The versions of FTM offerings are mapped to the versions of the Red Hat OpenShift operators to install and deploy the offering.

The following table shows the versions of the Red Hat OpenShift operators, operand, supported operands and case package versions that must be installed for the different versions of FTM. The version of the operator is incremented whenever a fix pack or interim fix is released for a version of the FTM offerings.
Table 1. FTM
IBM product version of FTM Channel Operator Operand Supported operands Case package version
4.0.10 stable-v4.9 4.9.0 4.0.10.0 The operands that are supported are shown in the following list.
  • 4.0.10.0
 4.9.0