Rolling back the upgrade

Consider rolling back the upgrade from 2.4.1 to your previous version only if you encounter serious issues, for example, if key functionality is broken or if your instance groups fail to work. If possible, try changing the instance group to fix the issue rather than rolling back the upgrade.

Before you begin

Before rolling back your upgrade, ensure you stop all workload.
Before you access the cluster management console, ensure that you clear the GUI work directories ($EGO_TOP/gui/work/ and $EGO_TOP/gui/workarea/). Ensure also that you clear your browser cache and cookies. As a cluster administrator, notify all users who connect to the cluster management console to clear their browser cache and cookies as well.

About this task

During a rollback, the order of the rolling upgrade process is reversed. You roll back your cluster-level upgrade and then the host-level upgrade. Typically, you might not need to roll back the upgrade on your hosts as well. If you must do this, first roll back the cluster, then roll back the individual hosts in reverse order of the upgrade.

Procedure

Follow these steps when your cluster is installed to a local file system:
1. Log on to your primary host as root or sudo to root (a user that has been set up in the egosetsudoers configuration file) if you installed IBM® Spectrum Conductor as root. If you didn’t install as root, you must log on with the cluster administrator ID. Ensure that your cluster has started, and run the cluster rollback command:
```
egoupgrade rollback cluster [-f] [-u user_account] [-x password]
```
  For syntax usage and details, see egoupgrade.
2. Source the environment:
  - (csh) source $EGO_TOP/cshrc.platform
  - (bash) . $EGO_TOP/profile.platform
3. Complete this step only to remove version 2.4.1 from your hosts. Typically, after you upgrade your hosts, you test that your host works properly before you upgrade the cluster-level configuration. Therefore, it is unlikely that you need to roll back the hosts to your previous version. However, if you must completely remove your upgraded version from each host, complete these steps:
  1. Log on to each of your compute hosts by using the same user account that you used to upgrade version 2.4.1, and run the host rollback command:
```
egoupgrade rollback host [-f]
```
    Note: If you run this command to roll back the upgrade on the local compute host, be aware that instance groups that require updated features cannot run on the compute host.
    For syntax usage and details, see egoupgrade.
  2. Source the environment:
    - (csh) source $EGO_TOP/cshrc.platform
    - (bash) . $EGO_TOP/profile.platform
  3. Repeat steps 3a and 3b on your management hosts. Log on to the host by using the same user account that you used to upgrade version 2.4.1.
  4. Repeat steps 3a and 3b on your primary candidate hosts. Log on to the host by using the same user account that you used to upgrade version 2.4.1.
  5. Repeat steps 3a and 3b on your primary host. Log on to the host by using the same user account that you used to upgrade version 2.4.1.
Follow these steps when your cluster is installed to a shared file system:
1. Source the environment:
  - (csh) source $EGO_TOP/cshrc.platform
  - (bash) . $EGO_TOP/profile.platform
2. Log on to your primary host as root or sudo to root (a user that has been set up in the egosetsudoers configuration file) if you installed IBM Spectrum Conductor as root. If you didn’t install as root, you must log on with the cluster administrator ID. Ensure that your cluster has started, and run the cluster rollback command:
```
egoupgrade rollback cluster [-f] [-u user_account] [-x password]
```
  For syntax usage and details, see egoupgrade.
3. If you must completely remove the configuration for your upgraded version, log on to any compute host in your cluster and run the host rollback command:
```
egoupgrade rollback host [-f]
```
  For syntax usage and details, see egoupgrade.
4. Source the environment:
  - (csh) source $EGO_TOP/cshrc.platform
  - (bash) . $EGO_TOP/profile.platform
5. Restart EGO on the local host:
```
egosh ego shutdown
egosh ego start
```
6. On all other compute hosts in your cluster, complete these steps:
  1. Source the environment:
    - (csh) source $EGO_TOP/cshrc.platform.comp
    - (bash) . $EGO_TOP/profile.platform.comp
  2. Restart EGO on the host:
```
egosh ego shutdown
egosh ego start
```
  Note: If you have more than one shared locations (for example, a separate share for management hosts and another for compute hosts), you manually updated the profile.platform.comp (or cshrc.platform.comp file if you are using CSH) on compute hosts. After you roll back your upgrade, before you source the environment, you must also edit the profile.platform.comp (cshrc.platform.comp) file to use the upgraded product version.
7. Repeat steps 3 and 4 on all management hosts in your cluster.
8. Repeat steps 3 and 4 on the primary host in your cluster.

Results

The 2.4.1 configurations (including configuration files, users and custom user roles, consumers, resource groups, resource plans, or custom reports; and enabled features) is rolled back to the previous version environment.

What to do next

After you roll back the upgrade, to ensure that elk-shipper service starts properly, replace these files, as follows:
1. Stop the elk-shipper service:
```
egosh service stop elk-shipper
```
2. Include the filebeat.yml.template and conductor.yml files into $EGO_TOP/integration/elk/conf/updatedfiles. For example:
```
echo "/filebeat.yml.template" >> $EGO_TOP/integration/elk/conf/updatedfiles
echo "/shipper/conductor.yml" >> $EGO_TOP/integration/elk/conf/updatedfiles
```
3. Once you have confirmed that the elk-shipper service has stopped, replace those files on all hosts:
  - Copy the $EGO_TOP/integration/elk/activation/conductorsparkcoreversion/conf/shipper/conductor.yml file to overwrite the $EGO_CONFDIR/../../integration/elk/conf/shipper/conductor.yml file.
  - Copy the $EGO_TOP/integration/elk/activation/version/conf/filebeat.yml.template file to overwrite the $EGO_CONFDIR/../../integration/elk/conf/filebeat.yml.template file.
  For example:
```
cp $EGO_TOP/integration/elk/activation/conductorsparkcoreversion/conf/shipper/conductor.yml $EGO_CONFDIR/../../integration/elk/conf/shipper/conductor.yml
cp $EGO_TOP/integration/elk/activation/version/conf/filebeat.yml.template $EGO_CONFDIR/../../integration/elk/conf/filebeat.yml.template
```
4. Restart the elk-shipper service for the changes to take effect:
```
egosh service start elk-shipper
```
Rolling back the upgrade to your previous version restores the configuration files, but not the product binaries, which remain and can affect your cluster if you plan to upgrade the product again. To ensure a clean environment, uninstall 2.4.1 (for details, see Uninstalling IBM Spectrum Conductor).
Run the egoupgrade cluster command to redo the cluster-level upgrade to version 2.4.1.
If you no longer want to upgrade, uninstall version 2.4.1 on your hosts. See Uninstalling IBM Spectrum Conductor.