Search
SupportConsoleDevelopersStart a trialContact

Updating OpenShift Container Storage

download PDF
Red Hat OpenShift Container Storage 4.7

Instructions for cluster and storage administrators

Red Hat Storage Documentation Team

Abstract

This document explains how to update Red Hat OpenShift Container Storage.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

Providing feedback on Red Hat documentation

We appreciate your input on our documentation. Do let us know how we can make it better. To give feedback:

  • For simple comments on specific passages:

    1. Make sure you are viewing the documentation in the Multi-page HTML format. In addition, ensure you see the Feedback button in the upper right corner of the document.
    2. Use your mouse cursor to highlight the part of text that you want to comment on.
    3. Click the Add Feedback pop-up that appears below the highlighted text.
    4. Follow the displayed instructions.

  • For submitting more complex feedback, create a Bugzilla ticket:

    1. Go to the Bugzilla website.
    2. As the Component, use Documentation.
    3. Fill in the Description field with your suggestion for improvement. Include a link to the relevant part(s) of documentation.
    4. Click Submit Bug.

Chapter 1. Overview of the OpenShift Container Storage update process

You can upgrade Red Hat OpenShift Container Storage and its components, either between minor releases like 4.6 and 4.7, or between batch updates like 4.7.0 and 4.7.1.

You need to upgrade the different parts of OpenShift Container Storage in a specific order.

  1. Update OpenShift Container Platform according to the Updating clusters documentation for OpenShift Container Platform.

  2. Update OpenShift Container Storage.

    1. To prepare a disconnected environment for updates, see Operators guide to using Operator Lifecycle Manager on restricted networks to be able to update Openshift Container Storage as well as Local Storage Operator when in use.

    2. Update the OpenShift Container Storage operator, using the appropriate process for your setup:

    3. If you use local storage:

      1. Update the Local Storage operator.

        See Checking for Local Storage Operator deployments if you are unsure.

      2. Perform post-update configuration changes for clusters backed by local storage.

        See Post-update configuration for clusters backed by local storage for details.

Update considerations

Review the following important considerations before you begin.

  • Red Hat recommends using the same version of Red Hat OpenShift Container Platform with Red Hat OpenShift Container Storage.

    See the Interoperability Matrix for more information about supported combinations of OpenShift Container Platform and OpenShift Container Storage.

  • The Local Storage Operator is fully supported only when the Local Storage Operator version matches the Red Hat OpenShift Container Platform version.

Chapter 2. OpenShift Container Storage upgrade channels and releases

In OpenShift Container Platform 4.1, Red Hat introduced the concept of channels for recommending the appropriate release versions for cluster upgrades. By controlling the pace of upgrades, these upgrade channels allow you to choose an upgrade strategy. As OpenShift Container Storage gets deployed as an Operator in OpenShift Container Platform, it follows the same strategy to control the pace of upgrades by shipping the fixes in multiple channels. Upgrade channels are tied to a minor version of OpenShift Container Storage. For example, OpenShift Container Storage 4.7 upgrade channels recommend upgrades from 4.6 to 4.7 and upgrades within 4.7. They do not recommend upgrades to 4.8 or later releases. This strategy ensures that administrators can explicitly decide to upgrade to the next minor version of OpenShift Container Storage.

Upgrade channels control only release selection and do not impact the version of the cluster that you install; the ocs-operator decides the version of OpenShift Container Storage to be installed. Out of the box, it always installs the latest OpenShift Container Storage release maintaining the compatibility with OpenShift Container Platform. So on OpenShift Container Platform 4.7, OpenShift Container Storage 4.7 will be the latest version which can be installed.

OpenShift Container Storage upgrades are tied to the OpenShift Container Platform upgrade to ensure that compatibility and interoperability are maintained with the OpenShift Container Platform. For OpenShift Container Storage 4.7, OpenShift Container Platform 4.7 and 4.8 are supported. OpenShift Container Platform 4.8 is supported to maintain forward compatibility with OpenShift Container Platform. Keep the OpenShift Container Storage version the same as OpenShift Container Platform in order to get the benefit of all the features and enhancements in that release.

OpenShift Container Platform 4.7 offers the following upgrade channel:

  • stable-4.7

    stable-4.7 channel
    Once a new version is Generally Available, the stable channel corresponding to the minor version gets updated with the new image which can be used to upgrade. You can use the stable-4.7 channel to upgrade from OpenShift Container storage 4.6 and upgrades within 4.7.

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.

Chapter 4. Updating OpenShift Container Storage in external mode

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

Important

Upgrading Red Hat OpenShift Container Storage Operator does not upgrade the external Red Hat Ceph Storage cluster. It only upgrades the Red Hat OpenShift Container Storage Services running on the OpenShift Container Platform.

To upgrade the external Red Hat Ceph Storage cluster contact your Red Hat Ceph Storage administrator.

4.1. Enabling automatic updates for OpenShift Container Storage operator in external mode

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

Note

Updating OpenShift Container Storage will not update the external Red Hat Ceph Storage cluster.

Prerequisites

  • Red Hat Ceph Storage version 4.2z1 or later is required for the external cluster. For more information, see this knowledge base article on Red Hat Ceph Storage releases and corresponding Ceph package versions.
  • 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.

  • Under Persistent Storage in the Status card, confirm that the OCS Cluster 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).
  • Ensure that you have sufficient time to complete the Openshift Container Storage update process.

Procedure

  1. Log in to OpenShift Web Console.
  2. Click Operators → Installed Operators
  3. Select the openshift-storage project.
  4. Click on 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 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 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 in 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.

4.2. Manually updating OpenShift Container Storage operator in external mode

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

Note

Updating OpenShift Container Storage will not update the external Red Hat Ceph Storage cluster.

Prerequisites

  • Red Hat Ceph Storage version 4.2z1 or later is required for the external cluster. For more information, see this knowledge base article on Red Hat Ceph Storage releases and corresponding Ceph package versions.
  • 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.

  • Under Persistent Storage in the Status card, confirm that the OCS Cluster 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).
  • Ensure that you have sufficient time to complete the Openshift Container Storage update process.

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 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 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 in Ready.

  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.

    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.

  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.

Chapter 5. Adding annotation to the pre-existing backingstores

Adding the correct annotation to the pre-existing backingstores allows the backingstores backed by object gateways (RGWs) to report its actual and free size. The Multicloud Object Gateway (MCG) can retrieve and use this information.

Procedure

  1. Log in to the OpenShift Container Platform Web Console.
  2. Click Home → Search.
  3. Search for BackingStore in Resources and click on it.
  4. Beside the S3-compatible BackingStore, click Action Menu (⋮) → Edit annotations.
  5. Add rgw for KEY.
  6. Click Save.

Next steps

For clusters backed by local storage, additional configuration steps are required after an update to ensure that all features work as expected.

For more information, see Post-update configuration changes for clusters backed by local storage.

Chapter 6. Post-update configuration changes for clusters backed by local storage

In clusters backed by local storage, additional configuration steps are required after an update to ensure that all features work as expected. In Red Hat OpenShift Container Platform 4.6 and onward, the Local Storage Operator provides new custom resource types for managing local storage:

  • LocalVolumeDiscovery
  • LocalVolumeSet

These resource types are not automatically handled as part of an update from earlier versions and must be created manually.

Note

If you had already created these resources after upgrading from 4.5 to 4.6, then you do not need to create them after upgrading from 4.6 to 4.7.

6.1. Creating a LocalVolumeDiscovery custom resource using the command line

Create a LocalVolumeDiscovery custom resource to ensure that the device management user interface can discover the state of local devices and provide information about devices that are available on cluster nodes.

Prerequisites

  • Administrative access to the OpenShift Container Platform cluster.

Procedure

  1. Identify the namespace where OpenShift local storage operator is installed and assign it to local_storage_project variable: 

    $ local_storage_project=$(oc get csv --all-namespaces | awk '{print $1}' | grep local)

    For example: 

    $ local_storage_project=$(oc get csv --all-namespaces | awk '{print $1}' | grep local)
echo $local_storage_project
openshift-local-storage

  2. Change into the project that has the Local Storage Operator installed. 

    $ oc project $local_storage_project

  3. Define the LocalVolumeDiscovery custom resource.

    For example, define the following in a local-volume-discovery.yaml file. 

    apiVersion: local.storage.openshift.io/v1alpha1
kind: LocalVolumeDiscovery
metadata:
  name: auto-discover-devices
spec:
  nodeSelector:
    nodeSelectorTerms:
      - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
              - worker1.example.com
              - worker2.example.com
              - worker3.example.com

  4. Create the LocalVolumeDiscovery custom resource. 

    $ oc create -f local-volume-discovery.yaml

Verification steps

  1. Log in to the OpenShift web console.
  2. Click Compute → Node and click on the name of the node.
  3. Click the Disks tab and check that you can see the devices available on that node.

6.2. Creating a LocalVolumeSet custom resource using the command line

Create a LocalVolumeSet custom resource to automatically provision certain storage devices as persistent volumes based on criteria that you specify. Persistent volumes are created for any devices that match the deviceInclusionSpec criteria on any node that matches the nodeSelector criteria.

Prerequisites

  • Administrative access to the OpenShift Container Platform cluster.

Procedure

  1. Define a LocalVolumeSet custom resource in a local-volume-set.yaml file. 

    apiVersion: local.storage.openshift.io/v1alpha1
kind: LocalVolumeSet
metadata:
  name: localblock
spec:
  nodeSelector:
    nodeSelectorTerms:
      - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
              - worker1.example.com
              - worker2.example.com
              - worker3.example.com
  storageClassName: localblock
  volumeMode: Block
  maxDeviceCount: 10 # optional, limit devices provisioned per node
  deviceInclusionSpec:
    deviceTypes: # list of types to allow
      - disk
      - part # omit this to use only whole devices
    deviceMechanicalProperty:
      - NonRotational
    minSize: 100Gi # optional, minimum size of device to allow
    maxSize: 100Ti # optional, maximum size of device to allow
    models: # (optional) list of models to allow
      - SAMSUNG
      - Crucial_CT525MX3
    vendors: # (optional) list of device vendors to allow
      - ATA
      - ST2000LM

    The above definition selects whole disks or partitions on specific models of non-rotational devices that are between 100 GB and 100 TB in size, provided by specific vendors, from the worker1, worker2 and worker3 nodes. The localblock storage class is created and persistent volumes are provisioned from discovered devices.

    Important

    Select an appropriate value for minSize to ensure system partitions are not selected.

  2. Create the LocalVolumeSet. 

    $ oc create -f local-volume-set.yaml

Verification steps

  1. Use the following command to track provisioning of persistent volumes for devices that match the deviceInclusionSpec. It can take a few minutes to provision persistent volumes. 

    $ oc describe localvolumeset localblock
[...]
Status:
  Conditions:
    Last Transition Time:          2020-11-17T05:03:32Z
    Message:                       DiskMaker: Available, LocalProvisioner: Available
    Status:                        True
    Type:                          DaemonSetsAvailable
    Last Transition Time:          2020-11-17T05:03:34Z
    Message:                       Operator reconciled successfully.
    Status:                        True
    Type:                          Available
  Observed Generation:             1
  Total Provisioned Device Count: 4
Events:
Type    Reason      Age          From                Message
----    ------      ----         ----                -------
Normal  Discovered  2m30s (x4    localvolumeset-     ip-10-0-147-124.us-east-
        NewDevice   over 2m30s)  symlink-controller  2.compute.internal -
                                                     found possible matching
                                                     disk, waiting 1m to claim
Normal  FoundMatch  89s (x4      localvolumeset-     ip-10-0-147-124.us-east-
        ingDisk     over 89s)    symlink-controller  2.compute.internal -
                                                     symlinking matching disk

  2. Verify the state of the provisioned persistent volumes. 

    $ oc get pv
                     ACCESS   RECLAIM             STORAGE
NAME       CAPACITY  MODES    POLICY   STATUS     CLASS       AGE
local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
3584969f
local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
3aee84fa
local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
644d09ac
local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
c73cee1

6.3. Adding annotations

Use this procedure to add annotations to storage cluster to enable replacing of failed storage devices through the user interface when you upgraded to OpenShift Container Storage 4.7 from a previous version.

Procedure

  1. Log in to OpenShift Container Platform Web Console.
  2. Click Home → Search.
  3. Search for StorageCluster in Resources and click on it.
  4. Beside ocs-storagecluster, click Action menu (⋮) → Edit annotations.
  5. Add cluster.ocs.openshift.io/local-devices and true for KEY and VALUE respectively.
  6. Click Save.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.