Post upgrade tasks

The following section describes actions to be done on the cluster to complete the upgrade of IBM Storage Scale container native to the new code levels.

Apply the patch to the cluster CR to enable network policies

Issue the following command to enable network policies to your IBM Storage Scale deployment:

oc patch cluster.scale.spectrum.ibm.com ibm-spectrum-scale --type='json' \
-p='[{"op": "add", "path": "/spec/networkPolicy", "value":{}}]'

For more information, see Network policies.

Approve the new release level

It is recommended to first use the cluster with the new code of IBM Storage Scale that is installed before you permanently upgrade the cluster to the new level. When you are ready to enable the new functions of the installed release and lock in the new level, you need to approve an UpgradeApproval resource. The operator will create an UpgradeApproval if a release level change is detected after the upgrade.

Upgrades within the .x version of a release typically do not have an upgrade approval.

For more information, see File system format changes between versions of IBM Storage Scale in the IBM Storage Scale documentation.

Complete the following steps:

Check to see whether any cluster upgrade approvals are present that require action.

An upgrade approval that shows nothing under the COMPLETED field are ones that require some action.
```
oc get upgradeapproval -n ibm-spectrum-scale
```
If an upgrade approval does not appear, check the Daemon CR status to validate that all pods are on the new version by using: oc get daemon -n ibm-spectrum-scale -ojson | jq -r .items[].status.versions

Check the minReleaseLevel of the cluster:

oc exec $(oc get pods -lapp.kubernetes.io/name=core -ojsonpath="{.items[0].metadata.name}" \
-n ibm-spectrum-scale) -c gpfs -n ibm-spectrum-scale -- mmlsconfig release

To approve the upgrade approval job, run the following command:

oc patch upgradeapproval <upgradeapproval-name> -n ibm-spectrum-scale --type='json' \
-p='[{"op": "replace", "path": "/spec/approved", "value":true}]'

Full Example:

# Check for any upgrade approvals for TYPE=cluster
$ oc get upgradeapproval -n ibm-spectrum-scale
NAME            TYPE      FILESYSTEM   LAST SCHEDULE TIME   LAST SUCCESSFUL TIME   RUNNING   COMPLETED
upgrade-rmlp4   cluster

# check the daemon status for the versions deployed on each core pod
$ oc get daemon -n ibm-spectrum-scale -ojson | jq  .items[].status.versions
[
  {
    "count": "3",
    "version": "5.1.9.1"
  }
]

# check the current cluster release version
$ oc exec $(oc get pods -lapp.kubernetes.io/name=core -ojsonpath="{.items[0].metadata.name}" -n ibm-spectrum-scale) -c gpfs -n ibm-spectrum-scale -- mmlsconfig release
minReleaseLevel 5.1.5.0

# patch the upgrade approval
$ oc patch upgradeapproval upgrade-rmlp4  -n ibm-spectrum-scale \
> --type='json'  -p='[{"op": "replace", "path": "/spec/approved", "value":true}]'
upgradeapproval.scale.spectrum.ibm.com/upgrade-rmlp4 patched

# query the upgrade approval to see it running
$ oc get upgradeapproval -n ibm-spectrum-scale
NAME            TYPE      FILESYSTEM   LAST SCHEDULE TIME   LAST SUCCESSFUL TIME   RUNNING                                                 COMPLETED
upgrade-rmlp4   cluster                23s                                         ibm-spectrum-scale/worker2/gpfs/upgradeCluster_p6Jhz9

# upgrade approval job completed
$ oc get upgradeapproval -n ibm-spectrum-scale
NAME            TYPE      FILESYSTEM   LAST SCHEDULE TIME   LAST SUCCESSFUL TIME   RUNNING   COMPLETED
upgrade-rmlp4   cluster                38s                  6s                               Successful

# verify that the cluster release level has been updated
$ oc exec $(oc get pods -lapp.kubernetes.io/name=core -ojsonpath="{.items[0].metadata.name}" -n ibm-spectrum-scale) -c gpfs -n ibm-spectrum-scale -- mmlsconfig release
minReleaseLevel 5.1.9.1

For more information, see Completing the upgrade to a new level of IBM Storage Scale in IBM Storage Scale documentation.

Remote storage cluster considerations

The storage cluster is supported to be down-level from the IBM Storage Scale container native cluster, but it is recommended that the versions match. CSI functions are highly dependent upon the IBM Storage Scale version and file system level installed on the storage cluster. If the storage cluster is running an earlier version, some functionality may not be available. For more information about CSI features and required levels, see Hardware and software requirements in IBM Storage Scale CSI documentation. For more information about compatibility and software matrix, see Section 17.3 in the IBM Storage Scale FAQ documentation.

Run the following step for each file system to upgrade to the latest metadata format:

If the storage cluster is being mounted by other GPFS client clusters that are running a prior version of code, performing the following step results in these client clusters being unable to mount file systems from this storage cluster.
```
 mmchfs <Filesystem> -V full
```
This step is optional but recommended for enabling the functions that are provided at the latest levels of code.
Enable auto-inode-limit of the file system.
```
 mmchfs <Filesystem> --auto-inode-limit
```
The --auto-inode-limit option is available only at file system format level of 28.00 or later. Enable this option when the file system is updated to 28.00 or later.

Remove deprecated resources

Some resources are deprecated in version 5.2.1, and they should be deleted.

Run the following steps to delete the deprecated resources:

```bash oc delete ClusterRoleBinding ibm-spectrum-scale-dns oc delete ClusterRole ibm-spectrum-scale-dns