Chapter 3. Updating OpenShift Container Storage in internal mode

Use the following procedures to update your OpenShift Container Storage cluster deployed in internal mode.

3.1. Enabling automatic updates for OpenShift Container Storage operator in internal mode

Use this procedure to enable automatic update approval for updating OpenShift Container Storage operator in OpenShift Container Platform.

Prerequisites

  • Under Persistent Storage in the Status card, confirm that the OCS Cluster and Data Resiliency has a green tick mark.
  • Under Object Service in the Status card, confirm that both the Object Service and Data Resiliency are in Ready state (green tick).
  • Update the OpenShift Container Platform cluster to the latest stable release of version 4.7.Y, see Updating Clusters.

  • Switch the Red Hat OpenShift Container Storage channel from stable-4.6 to stable-4.7. For details about channels, see OpenShift Container Storage upgrade channels and releases.

    Note

    You are required to switch channels only when you are updating minor versions (for example, updating from 4.6 to 4.7) and not when updating between batch updates of 4.7 (for example, updating from 4.7.0 to 4.7.1).

  • Ensure that all OpenShift Container Storage Pods, including the operator pods, are in Running state in the openshift-storage namespace.

    To view the state of the pods, click Workloads → Pods from the left pane of the OpenShift Web Console. Select openshift-storage from the Project drop down list.

  • Ensure that you have sufficient time to complete the Openshift Container Storage update process, as the update time varies depending on the number of OSDs that run in the cluster.

Procedure

  1. Log in to OpenShift Web Console.
  2. Click Operators → Installed Operators
  3. Select the openshift-storage project.
  4. Click the OpenShift Container Storage operator name.
  5. Click the Subscription tab and click the link under Approval.
  6. Select Automatic (default) and click Save.

  7. Perform one of the following depending on the Upgrade Status:

    • Upgrade Status shows requires approval.

      Note

      Upgrade status shows requires approval if the new OpenShift Container Storage version is already detected in the channel, and approval strategy was changed from Manual to Automatic at the time of update.

      1. Click on the Install Plan link.
      2. On the InstallPlan Details page, click Preview Install Plan.
      3. Review the install plan and click Approve.
      4. Wait for the Status to change from Unknown to Created.
      5. Click Operators → Installed Operators
      6. Select the openshift-storage project.
      7. Wait for the Status to change to Up to date

    • Upgrade Status does not show requires approval:

      1. Wait for the update to initiate. This may take up to 20 minutes.
      2. Click Operators → Installed Operators
      3. Select the openshift-storage project.
      4. Wait for the Status to change to Up to date
Note

Multicloud Object Gateway outage is expected for a short period of time during upgrade due to migration of NooBaa DB from MongoDB to PostgreSQL.

Verification steps

  1. Click Overview → Persistent Storage tab and in the Status card confirm that the OCS Cluster and Data Resiliency has a green tick mark indicating it is healthy.
  2. Click Overview → Object Service tab and in the Status card confirm that both the Object Service and Data Resiliency are in Ready state (green tick) indicating it is healthy.

  3. Click Operators → Installed Operators → OpenShift Container Storage Operator. Under Storage Cluster, verify that the cluster service status is Ready.

    Note

    Once updated from OpenShift Container Storage version 4.6 to 4.7, the Version field here will still display 4.6. This is because the ocs-operator does not update the string represented in this field.

  4. Ensure that all OpenShift Container Storage Pods, including the operator pods, are in Running state in the openshift-storage namespace.

    To view the state of the pods, click Workloads → Pods. Select openshift-storage from the Project drop down list.

  5. If verification steps fail, contact Red Hat Support.
Note

The flexible scaling feature is available only in the new deployments of Red Hat OpenShift Container Storage 4.7. Storage clusters upgraded to the 4.7 version do not support flexible scaling.

Next steps

Additional Resources

If you face any issues while updating OpenShift Container Storage, see the Commonly required logs for troubleshooting section in the Troubleshooting guide.

3.2. Manually updating OpenShift Container Storage operator in internal mode

Use this procedure to update OpenShift Container Storage operator by providing manual approval to the install plan.

Prerequisites

  • Under Persistent Storage in the Status card, confirm that the OCS Cluster and Data Resiliency has a green tick mark.
  • Under Object Service in the Status card, confirm that both the Object Service and Data Resiliency are in Ready state (green tick).
  • Update the OpenShift Container Platform cluster to the latest stable release of version 4.7.Y, see Updating Clusters.

  • Switch the Red Hat OpenShift Container Storage channel from stable-4.6 to stable-4.7. For details about channels, see OpenShift Container Storage upgrade channels and releases.

    Note

    You are required to switch channels only when you are updating minor versions (for example, updating from 4.6 to 4.7) and not when updating between batch updates of 4.7 (for example, updating from 4.7.0 to 4.7.1).

  • Ensure that all OpenShift Container Storage Pods, including the operator pods, are in Running state in the openshift-storage namespace.

    To view the state of the pods, click Workloads → Pods from the left pane of the OpenShift Web Console. Select openshift-storage from the Project drop down list.

  • Ensure that you have sufficient time to complete the Openshift Container Storage update process, as the update time varies depending on the number of OSDs that run in the cluster.

Procedure

  1. Log in to OpenShift Web Console.
  2. Click Operators → Installed Operators
  3. Select the openshift-storage project.
  4. Click the OpenShift Container Storage operator name.
  5. Click the Subscription tab and click the link under Approval.
  6. Select Manual and click Save.
  7. Wait for the Upgrade Status to change to Upgrading.
  8. If the Upgrade Status shows requires approval, click on requires approval.
  9. On the InstallPlan Details page, click Preview Install Plan.
  10. Review the install plan and click Approve.
  11. Wait for the Status to change from Unknown to Created.
  12. Click Operators → Installed Operators
  13. Select the openshift-storage project.
  14. Wait for the Status to change to Up to date
Note

Multicloud Object Gateway outage is expected for a short period of time during upgrade due to migration of NooBaa DB from MongoDB to PostgreSQL.

Verification steps

  1. Click Overview → Persistent Storage tab and in the Status card confirm that the OCS Cluster and Data Resiliency has a green tick mark indicating it is healthy.
  2. Click Overview → Object Service tab and in the Status card confirm that both the Object Service and Data Resiliency are in Ready state (green tick) indicating it is healthy.

  3. Click Operators → Installed Operators → OpenShift Container Storage Operator. Under Storage Cluster, verify that the cluster service status is Ready.

    Note

    Once updated from OpenShift Container Storage version 4.6 to 4.7, the Version field here will still display 4.6. This is because the ocs-operator does not update the string represented in this field.

  4. Ensure that all OpenShift Container Storage Pods, including the operator pods, are in Running state in the openshift-storage namespace.

    To view the state of the pods, click Workloads → Pods from the left pane of the OpenShift Web Console. Select openshift-storage from the Project drop down list.

  5. If verification steps fail, contact Red Hat Support.

Next steps

Additional Resources

If you face any issues while updating OpenShift Container Storage, see the Commonly required logs for troubleshooting section in the Troubleshooting guide.