Procedure

1. Log in to the Red Hat Enterprise Linux based node and open a terminal.

2. For each node in your cluster:

   1. Verify that the node has access to the rhel-7-server-extras-rpms repository.

      # subscription-manager repos --list-enabled | grep rhel-7-server

      If you do not see both rhel-7-server-rpms and rhel-7-server-extras-rpms in the output, or if there is no output, run the following commands to enable each repository.

      # subscription-manager repos --enable=rhel-7-server-rpms
      # subscription-manager repos --enable=rhel-7-server-extras-rpms

   2. Install the required packages.

      # yum install -y policycoreutils container-selinux

   3. Persistently enable container use of the Ceph file system in SELinux.

      # setsebool -P container_use_cephfs on

Procedure

1. Enable the Key/Value (KV) backend path in Vault.

   For Vault KV secret engine API, version 1:

   $ vault secrets enable -path=ocs kv

   For Vault KV secret engine API, version 2:

   $ vault secrets enable -path=ocs kv-v2

2. Create a policy to restrict users to perform a write or delete operation on the secret using the following commands:

   echo '
   path "ocs/*" {
     capabilities = ["create", "read", "update", "delete", "list"]
   }
   path "sys/mounts" {
   capabilities = ["read"]
   }'| vault policy write ocs -

3. Create a token matching the above policy:

   $ vault token create -policy=ocs -format json

Procedure

1. Log in to OpenShift Web Console.
2. Click Operators → OperatorHub.
3. Search for OpenShift Container Storage from the list of operators and click on it.
4. Click Install.

5. Set the following options on the Install Operator page:

   1. Channel as stable-4.8.
   2. Installation Mode as A specific namespace on the cluster.
   3. Installed Namespace as Operator recommended namespace openshift-storage. If Namespace openshift-storage does not exist, it will be created during the operator installation.
   4. Approval Strategy as Automatic or Manual.

   5. Click Install.

      If you select Automatic updates, the Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your operator without any intervention.

      If you select Manual updates, the OLM creates an update request. As a cluster administrator, you must then manually approve that update request to have the operator updated to the new version.

Procedure

1. Log into the OpenShift Web Console.

2. Click Operators → Installed Operators to view all the installed operators.

   Ensure that the Project selected is openshift-storage.

3. Click OpenShift Container Storage > Create Instance link of Storage Cluster.
4. Select Mode is set to Internal by default.

5. Select Capacity and nodes

   1. Select Storage Class.

      By default, it is set to thin. If you have created a storage class with zeroedthick or eagerzeroedthick disk format for thick-provisioned storage, then that storage class is listed in addition to the default, thin storage class.

   2. Select Requested Capacity from the drop down list. It is set to 2 TiB by default. You can use the drop down to modify the capacity value.

      Note

      Once you select the initial storage capacity, cluster expansion is performed only using the selected usable capacity (3 times of raw storage).

   3. In the Select Nodes section, select at least three available nodes.

      Spread the worker nodes across three different physical nodes, racks or failure domains for high availability.

      Use vCenter anti-affinity to align OpenShift Container Storage rack labels with physical nodes and racks in the data center to avoid scheduling two worker nodes on the same physical chassis.

      If the nodes selected do not match the OpenShift Container Storage cluster requirement of an aggregated 30 CPUs and 72 GiB of RAM, a minimal cluster will be deployed. For minimum starting node requirements, see Resource requirements section in Planning guide.

   4. Click Next.

6. (Optional) Set Security and network configuration

   1. Select the Enable encryption checkbox to encrypt block and file storage.

   2. Choose any one or both Encryption level:

      • Cluster-wide encryption to encrypt the entire cluster (block and file).
      • Storage class encryption to create encrypted persistent volume (block only) using encryption enabled storage class.

   3. Select the Connect to an external key management service checkbox. This is optional for cluster-wide encryption.

      1. Key Management Service Provider is set to Vault by default.
      2. Enter Vault Service Name, host Address of Vault server ('https://<hostname or ip>'), Port number and Token.

      3. Expand Advanced Settings to enter additional settings and certificate details based on your Vault configuration:

         1. Enter the Key Value secret path in Backend Path that is dedicated and unique to OpenShift Container Storage.
         2. (Optional) Enter TLS Server Name and Vault Enterprise Namespace.
         3. Provide CA Certificate, Client Certificate and Client Private Key by uploading the respective PEM encoded certificate file.
         4. Click Save.

7. Select Default (SDN) if you are using a single network or Custom (Multus) Network if you plan on using multiple network interfaces.

   1. Select a Public Network Interface from drop down.

   2. Select a Cluster Network Interface from drop down.

      Note

      If only using one additional network interface select the single NetworkAttachementDefinition (i.e. ocs-public-cluster) for the Public Network Interface and leave the Cluster Network Interface blank.

8. Click Next.
9. Review the configuration details. To modify any configuration settings, click Back to go back to the previous configuration page.
10. Click Create.

11. Edit the configmap if Vault Key/Value (KV) secret engine API, version 2 is used for cluster-wide encryption with Key Management System (KMS).

    1. On the OpenShift Web Console, navigate to Workloads → ConfigMaps.
    2. To view the KMS connection details, click ocs-kms-connection-details.

    3. Edit the configmap.

       1. Click Action menu (⋮) → Edit ConfigMap.

       2. Set the VAULT_BACKEND parameter to v2.

          kind: ConfigMap
          apiVersion: v1
          metadata:
            name: ocs-kms-connection-details
          [...]
          data:
            KMS_PROVIDER: vault
            KMS_SERVICE_NAME: vault
          [...]
            VAULT_BACKEND: v2
          [...]

       3. Click Save.

Verification steps

1. On the storage cluster details page, the storage cluster name displays a green tick next to it to indicate that the cluster was created successfully.

2. Verify that the final Status of the installed storage cluster shows as Phase: Ready with a green tick mark.

   • Click Operators → Installed Operators → Storage Cluster link to view the storage cluster installation status.
   • Alternatively, when you are on the Operator Details tab, you can click on the Storage Cluster tab to view the status.
3. To verify that all components for OpenShift Container Storage are successfully installed, see Verifying your OpenShift Container Storage installation.
4. To verify the multi network plug-in (Multus), see Verifying the Multus plug-in.

Procedure

1. Log in to the OpenShift Web Console.
2. Click Operators → OperatorHub.
3. Type local storage in the Filter by keyword…​ box to search for Local Storage operator from the list of operators and click on it.
4. Click Install.

5. Set the following options on the Install Operator page:

   1. Channel as stable-4.8.
   2. Installation Mode as A specific namespace on the cluster.
   3. Installed Namespace as Operator recommended namespace openshift-local-storage.
   4. Approval Strategy as Automatic.
6. Click Install.

Procedure

1. Log in to OpenShift Web Console.
2. Click Operators → OperatorHub.
3. Search for OpenShift Container Storage from the list of operators and click on it.
4. Click Install.

5. Set the following options on the Install Operator page:

   1. Channel as stable-4.8.
   2. Installation Mode as A specific namespace on the cluster.
   3. Installed Namespace as Operator recommended namespace openshift-storage. If Namespace openshift-storage does not exist, it will be created during the operator installation.
   4. Approval Strategy as Automatic or Manual.

   5. Click Install.

      If you select Automatic updates, the Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your operator without any intervention.

      If you select Manual updates, the OLM creates an update request. As a cluster administrator, you must then manually approve that update request to have the operator updated to the new version.

Procedure

1. Log into the OpenShift Web Console.

2. Click Operators → Installed Operators to view all the installed operators.

   Ensure that the Project selected is openshift-storage.

3. Click OpenShift Container Storage > Create Instance link of Storage Cluster.

4. Choose Select Mode as Internal-Attached devices.

   Note

   You are prompted to install the Local Storage Operator if it is not already installed. Click Install and follows procedure as described in Installing Local Storage Operator.

5. Discover disks

   1. Choose one of the following:

      • All nodes to discover disks in all the nodes.

      • Select nodes to discover disks from a subset of available nodes.

        Important

        For using arbiter mode, do not select the All nodes option. Instead, use the Select nodes option to select the labeled nodes with attached storage device(s) from the two data-center zones.

   2. Click Next.

6. Create Storage class.

   You can create a dedicated storage class to consume storage by filtering a set of storage volumes.

   1. Enter the Local Volume Set Name.
   2. Enter the Storage Class Name. By default, the volume set name appears for the storage class name. You can also change the name.

   3. The nodes selected for disk discovery in the previous step are displayed in the Filter Disks By section. Choose one of the following:

      • Disks on all nodes to select all the nodes for which you discovered the devices.

      • Disks on select nodes to select a subset of the nodes for which you discovered the devices. Spread the worker nodes across three different physical nodes, racks or failure domains for high availability.

        Important

        The flexible scaling feature gets enabled on creating a storage cluster with 3 or more nodes spread across fewer than the minimum requirement of 3 availability zones. This feature is available only for the new deployments of OpenShift Container Storage 4.7 clusters and does not support the upgraded clusters. For information about flexible scaling, see Scaling Storage Guide.

        Note

        If the nodes to be selected are tainted and not discovered in the wizard, follow the steps provided in the Red Hat Knowledgebase Solution as a workaround to add tolerations for Local Storage Operator resources.

   4. Select SSD/NVME Disk Type from the available list.

   5. Expand the Advanced section and set the following options:

      Volume Mode	Block is selected by default.
      Device Type	Select one or more disk type from the drop down list.
      Disk Size	Set a minimum size of 100GB for the device and maximum available size of the device that needs to be included.
      Maximum Disk Limit	This indicates the maximum number of PVs that can be created on a node. If this field is left empty, then PVs are created for all the available disks on the matching nodes.

   6. Click Next. A pop-up to confirm creation of the new storage class is displayed.
   7. Click Yes to continue.

7. Set Capacity and nodes

   1. Select Storage Class. By default, the new storage class created in the previous step is selected.
   2. Selected Nodes shows the nodes selected in the previous step. This list takes a few minutes to reflect the disks that were discovered in the previous step.
   3. Click Next.

8. (Optional) Set Security and network configuration

   1. Select Enable encryption checkbox to encrypt block and file storage.

   2. Choose one of the following Encryption level:

      • Cluster-wide encryption to encrypt the entire cluster (block and file).
      • Storage class encryption to create encrypted persistent volume (block only) using encryption enabled storage class.

   3. Select Connect to an external key management service checkbox. This is optional for cluster-wide encryption.

      1. Key Management Service Provider is set to Vault by default.
      2. Enter Vault Service Name, host Address of Vault server ('https://<hostname or ip>''), Port number and Token.

      3. Expand Advanced Settings to enter additional settings and certificate details based on your Vault configuration:

         1. Enter the Key Value secret path in Backend Path that is dedicated and unique to OpenShift Container Storage.
         2. (Optional) Enter TLS Server Name and Vault Enterprise Namespace.
         3. Provide CA Certificate, Client Certificate and Client Private Key by uploading the respective PEM encoded certificate file.
         4. Click Save.

9. Select Default (SDN) if you are using a single network or Custom (Multus) Network if you plan on using multiple network interfaces.

   1. Select a Public Network Interface from drop down.

   2. Select a Cluster Network Interface from drop down.

      Note

      If only using one additional network interface select the single NetworkAttachementDefinition (i.e. ocs-public-cluster) for the Public Network Interface and leave the Cluster Network Interface blank.

10. Click Next.
11. Review the configuration details. To modify any configuration settings, click Back to go back to the previous configuration page.
12. Click Create.

13. Edit the configmap if Vault Key/Value (KV) secret engine API, version 2 is used for cluster-wide encryption with Key Management System (KMS).

    1. On the OpenShift Web Console, navigate to Workloads → ConfigMaps.
    2. To view the KMS connection details, click ocs-kms-connection-details.

    3. Edit the configmap.

       1. Click Action menu (⋮) → Edit ConfigMap.

       2. Set the VAULT_BACKEND parameter to v2.

          kind: ConfigMap
          apiVersion: v1
          metadata:
            name: ocs-kms-connection-details
          [...]
          data:
            KMS_PROVIDER: vault
            KMS_SERVICE_NAME: vault
          [...]
            VAULT_BACKEND: v2
          [...]

       3. Click Save.

Procedure

1. Log in to OpenShift Web Console.
2. Click Workloads → Pods from the left pane of the OpenShift Web Console.

3. Select openshift-storage from the Project drop down list.

   For more information on the expected number of pods for each component and how it varies depending on the number of nodes, see Table 4.1, “Pods corresponding to OpenShift Container storage cluster”.

4. Click on the Running and Completed tabs to verify that the pods are running and in a completed state:

   Table 4.1. Pods corresponding to OpenShift Container storage cluster

   Component	Corresponding pods
   OpenShift Container Storage Operator	ocs-operator-* (1 pod on any worker node) ocs-metrics-exporter-*
   Rook-ceph Operator	rook-ceph-operator-* (1 pod on any worker node)
   Multicloud Object Gateway	noobaa-operator-* (1 pod on any worker node) noobaa-core-* (1 pod on any storage node) noobaa-db-pg-* (1 pod on any storage node) noobaa-endpoint-* (1 pod on any storage node)
   MON	rook-ceph-mon-* (3 pods distributed across storage nodes)
   MGR	rook-ceph-mgr-* (1 pod on any storage node)
   MDS	rook-ceph-mds-ocs-storagecluster-cephfilesystem-* (2 pods distributed across storage nodes)
   RGW	rook-ceph-rgw-ocs-storagecluster-cephobjectstore-* (1 pod on any storage node)
   CSI	cephfs csi-cephfsplugin-* (1 pod on each worker node) csi-cephfsplugin-provisioner-* (2 pods distributed across worker nodes) rbd csi-rbdplugin-* (1 pod on each worker node) csi-rbdplugin-provisioner-* (2 pods distributed across worker nodes)
   rook-ceph-crashcollector	rook-ceph-crashcollector-* (1 pod on each storage node)
   OSD	rook-ceph-osd-* (1 pod for each device) rook-ceph-osd-prepare-ocs-deviceset-* (1 pod for each device)

Procedure

1. Click Storage → Overview and click the Block and File tab.
2. In the Status card, verify that Storage Cluster and Data Resiliency has a green tick mark.
3. In the Details card, verify that the cluster information is displayed.

Procedure

1. Click Storage → Overview from the OpenShift Web Console and click the Object tab.
2. In the Status card, verify that both Object Service and Data Resiliency are in Ready state (green tick).
3. In the Details card, verify that the Multicloud Object Gateway information is displayed.

Procedure

1. Click Storage → Storage Classes from the OpenShift Web Console.

2. Verify that the following storage classes are created with the OpenShift Container Storage cluster creation:

   • ocs-storagecluster-ceph-rbd
   • ocs-storagecluster-cephfs
   • openshift-storage.noobaa.io
   • ocs-storagecluster-ceph-rgw

Procedure

1. Based on your network configuration choices, the OpenShift Container Storage operator does one of the following:

   • If only a single NetworkAttachmentDefinition (for example, ocs-public-cluster) is selected for the Public Network Interface, the traffic between the application pods and the OpenShift Container Storage cluster happens on this network. Additionally, the cluster is also self configured to use this network for the replication and rebalancing traffic between OSDs.
   • If both NetworkAttachmentDefinitions (for example, ocs-public and ocs-cluster) are selected for the Public Network Interface and the Cluster Network Interface respectively during the storage cluster installation, then client storage traffic is on the public network and cluster network is for the replication and rebalancing traffic between OSDs.

2. To verify the network configuration is correct, follow the steps:

   1. In the OpenShift console, click Installed Operators → Storage Cluster → ocs-storagecluster.

   2. In the YAML tab, search for network in the spec section and ensure the configuration is correct for your network interface choices. This example is for separating the client storage traffic from the storage replication traffic.

      Sample output:

      [..]
      spec:
          [..]
          network:
          provider: multus
          selectors:
            cluster: openshift-storage/ocs-cluster
            public: openshift-storage/ocs-public
          [..]

3. To verify the network configuration is correct using the command line interface, run the following commands:

   $ oc get storagecluster ocs-storagecluster \
   -n openshift-storage \
   -o=jsonpath='{.spec.network}{"\n"}'

   Sample output:

   {"provider":"multus","selectors":{"cluster":"openshift-storage/ocs-cluster","public":"openshift-storage/ocs-public"}}

4. Confirm the OSD pods are using correct network:

   1. In the openshift-storage namespace use one of the OSD pods to verify the pod has connectivity to the correct networks. This example is for separating the client storage traffic from the storage replication traffic.

      Note

      Only the OSD pods connects to both Multus public and cluster networks if both are created. All other OCS pods connect to the Multus public network.

      $ oc get -n openshift-storage $(oc get pods -n openshift-storage -o name -l app=rook-ceph-osd | grep 'osd-0') -o=jsonpath='{.metadata.annotations.k8s\.v1\.cni\.cncf\.io/network-status}{"\n"}'

      Sample output:

      [{
          "name": "openshift-sdn",
          "interface": "eth0",
          "ips": [
              "10.129.2.30"
          ],
          "default": true,
          "dns": {}
      },{
          "name": "openshift-storage/ocs-cluster",
          "interface": "net1",
          "ips": [
              "192.168.2.1"
          ],
          "mac": "e2:04:c6:81:52:f1",
          "dns": {}
      },{
          "name": "openshift-storage/ocs-public",
          "interface": "net2",
          "ips": [
              "192.168.1.1"
          ],
          "mac": "ee:a0:b6:a4:07:94",
          "dns": {}
      }]

5. To confirm the OSD pods are using correct network using the command line interface, run the following command (requires the jq utility):

   $ oc get -n openshift-storage $(oc get pods -n openshift-storage -o name -l app=rook-ceph-osd | grep 'osd-0') -o=jsonpath='{.metadata.annotations.k8s\.v1\.cni\.cncf\.io/network-status}{"\n"}' | jq -r '.[].name'

   Sample output:

   openshift-sdn
   openshift-storage/ocs-cluster
   openshift-storage/ocs-public

Procedure

1. Delete the volume snapshots that are using OpenShift Container Storage.

   1. List the volume snapshots from all the namespaces.

      $ oc get volumesnapshot --all-namespaces

   2. From the output of the previous command, identify and delete the volume snapshots that are using OpenShift Container Storage.

      $ oc delete volumesnapshot <VOLUME-SNAPSHOT-NAME> -n <NAMESPACE>

2. Delete PVCs and OBCs that are using OpenShift Container Storage.

   In the default uninstall mode (graceful), the uninstaller waits till all the PVCs and OBCs that use OpenShift Container Storage are deleted.

   If you wish to delete the Storage Cluster without deleting the PVCs beforehand, you may set the uninstall mode annotation to forced and skip this step. Doing this results in orphan PVCs and OBCs in the system.

   1. Delete OpenShift Container Platform monitoring stack PVCs using OpenShift Container Storage.

      For more information, see Section 5.2, “Removing monitoring stack from OpenShift Container Storage”.

   2. Delete OpenShift Container Platform Registry PVCs using OpenShift Container Storage.

      For more information, see Section 5.3, “Removing OpenShift Container Platform registry from OpenShift Container Storage”.

   3. Delete OpenShift Container Platform logging PVCs using OpenShift Container Storage.

      For more information, see Section 5.4, “Removing the cluster logging operator from OpenShift Container Storage”.

   4. Delete other PVCs and OBCs provisioned using OpenShift Container Storage.

      • Following script is sample script to identify the PVCs and OBCs provisioned using OpenShift Container Storage. The script ignores the PVCs that are used internally by Openshift Container Storage.

        #!/bin/bash
        
        RBD_PROVISIONER="openshift-storage.rbd.csi.ceph.com"
        CEPHFS_PROVISIONER="openshift-storage.cephfs.csi.ceph.com"
        NOOBAA_PROVISIONER="openshift-storage.noobaa.io/obc"
        RGW_PROVISIONER="openshift-storage.ceph.rook.io/bucket"
        
        NOOBAA_DB_PVC="noobaa-db"
        NOOBAA_BACKINGSTORE_PVC="noobaa-default-backing-store-noobaa-pvc"
        
        # Find all the OCS StorageClasses
        OCS_STORAGECLASSES=$(oc get storageclasses | grep -e "$RBD_PROVISIONER" -e "$CEPHFS_PROVISIONER" -e "$NOOBAA_PROVISIONER" -e "$RGW_PROVISIONER" | awk '{print $1}')
        
        # List PVCs in each of the StorageClasses
        for SC in $OCS_STORAGECLASSES
        do
                echo "======================================================================"
                echo "$SC StorageClass PVCs and OBCs"
                echo "======================================================================"
                oc get pvc  --all-namespaces --no-headers 2>/dev/null | grep $SC | grep -v -e "$NOOBAA_DB_PVC" -e "$NOOBAA_BACKINGSTORE_PVC"
                oc get obc  --all-namespaces --no-headers 2>/dev/null | grep $SC
                echo
        done

        Note

        Omit RGW_PROVISIONER for cloud platforms.

      • Delete the OBCs.

        $ oc delete obc <obc name> -n <project name>

      • Delete the PVCs.

        $ oc delete pvc <pvc name> -n <project-name>

        Note

        Ensure that you have removed any custom backing stores, bucket classes, etc., created in the cluster.

3. Delete the Storage Cluster object and wait for the removal of the associated resources.

   $ oc delete -n openshift-storage storagecluster --all --wait=true

4. Check for cleanup pods if the uninstall.ocs.openshift.io/cleanup-policy was set to delete(default) and ensure that their status is Completed.

   $ oc get pods -n openshift-storage | grep -i cleanup
   NAME                                READY   STATUS      RESTARTS   AGE
   cluster-cleanup-job-<xx>        	0/1     Completed   0          8m35s
   cluster-cleanup-job-<yy>     		0/1     Completed   0          8m35s
   cluster-cleanup-job-<zz>     		0/1     Completed   0          8m35s

5. Confirm that the directory /var/lib/rook is now empty. This directory will be empty only if the uninstall.ocs.openshift.io/cleanup-policy annotation was set to delete(default).

   $ for i in $(oc get node -l cluster.ocs.openshift.io/openshift-storage= -o jsonpath='{ .items[*].metadata.name }'); do oc debug node/${i} -- chroot /host  ls -l /var/lib/rook; done

6. If encryption was enabled at the time of install, remove dm-crypt managed device-mapper mapping from OSD devices on all the OpenShift Container Storage nodes.

   1. Create a debug pod and chroot to the host on the storage node.

      $ oc debug node/<node name>
      $ chroot /host

   2. Get Device names and make note of the OpenShift Container Storage devices.

      $ dmsetup ls
      ocs-deviceset-0-data-0-57snx-block-dmcrypt (253:1)

   3. Remove the mapped device.

      $ cryptsetup luksClose --debug --verbose ocs-deviceset-0-data-0-57snx-block-dmcrypt

      Note

      If the above command gets stuck due to insufficient privileges, run the following commands:

      • Press CTRL+Z to exit the above command.

      • Find PID of the process which was stuck.

        $ ps -ef | grep crypt

      • Terminate the process using kill command.

        $ kill -9 <PID>

      • Verify that the device name is removed.

        $ dmsetup ls

7. Delete the namespace and wait till the deletion is complete. You need to switch to another project if openshift-storage is the active project.

   For example:

   $ oc project default
   $ oc delete project openshift-storage --wait=true --timeout=5m

   The project is deleted if the following command returns a NotFound error.

   $ oc get project openshift-storage

   Note

   While uninstalling OpenShift Container Storage, if namespace is not deleted completely and remains in Terminating state, perform the steps in Troubleshooting and deleting remaining resources during Uninstall to identify objects that are blocking the namespace from being terminated.

8. Delete the local storage operator configurations if you have deployed OpenShift Container Storage using local storage devices. See Removing local storage operator configurations.

9. Unlabel the storage nodes.

   $ oc label nodes  --all cluster.ocs.openshift.io/openshift-storage-
   $ oc label nodes  --all topology.rook.io/rack-

10. Remove the OpenShift Container Storage taint if the nodes were tainted.

    $ oc adm taint nodes --all node.ocs.openshift.io/storage-

11. Confirm all PVs provisioned using OpenShift Container Storage are deleted. If there is any PV left in the Released state, delete it.

    $ oc get pv
    $ oc delete pv <pv name>

12. Delete the Multicloud Object Gateway storageclass.

    $ oc delete storageclass openshift-storage.noobaa.io --wait=true --timeout=5m

13. Remove CustomResourceDefinitions.

    $ oc delete crd backingstores.noobaa.io bucketclasses.noobaa.io cephblockpools.ceph.rook.io cephclusters.ceph.rook.io cephfilesystems.ceph.rook.io cephnfses.ceph.rook.io cephobjectstores.ceph.rook.io cephobjectstoreusers.ceph.rook.io noobaas.noobaa.io ocsinitializations.ocs.openshift.io storageclusters.ocs.openshift.io cephclients.ceph.rook.io cephobjectrealms.ceph.rook.io cephobjectzonegroups.ceph.rook.io cephobjectzones.ceph.rook.io cephrbdmirrors.ceph.rook.io --wait=true --timeout=5m

14. Optional: To ensure that the vault keys are deleted permanently you need to manually delete the metadata associated with the vault key.

    Note

    Execute this step only if Vault Key/Value (KV) secret engine API, version 2 is used for cluster-wide encryption with Key Management System (KMS) since the vault keys are marked as deleted and not permanently deleted during the uninstallation of OpenShift Container Storage. You can always restore it later if required.

    1. List the keys in the vault.

       $ vault kv list <backend_path>

       <backend_path>

       Is the path in the vault where the encryption keys are stored.

       For example:

       $ vault kv list kv-v2

       Example output:

       Keys
       -----
       NOOBAA_ROOT_SECRET_PATH/
       rook-ceph-osd-encryption-key-ocs-deviceset-thin-0-data-0m27q8
       rook-ceph-osd-encryption-key-ocs-deviceset-thin-1-data-0sq227
       rook-ceph-osd-encryption-key-ocs-deviceset-thin-2-data-0xzszb

    2. List the metadata associated with the vault key.

       $ vault kv get kv-v2/<key>

       For the Multicloud Object Gateway (MCG) key:

       $ vault kv get kv-v2/NOOBAA_ROOT_SECRET_PATH/<key>

       <key>

       Is the encryption key.

       For Example:

       $ vault kv get kv-v2/rook-ceph-osd-encryption-key-ocs-deviceset-thin-0-data-0m27q8

       Example output:

       ====== Metadata ======
       Key              Value
       ---              -----
       created_time     2021-06-23T10:06:30.650103555Z
       deletion_time    2021-06-23T11:46:35.045328495Z
       destroyed        false
       version          1

    3. Delete the metadata.

       $ vault kv metadata delete kv-v2/<key>

       For the MCG key:

       $ vault kv metadata delete kv-v2/NOOBAA_ROOT_SECRET_PATH/<key>

       <key>

       Is the encryption key.

       For Example:

       $ vault kv metadata delete kv-v2/rook-ceph-osd-encryption-key-ocs-deviceset-thin-0-data-0m27q8

       Example output:

       Success! Data deleted (if it existed) at: kv-v2/metadata/rook-ceph-osd-encryption-key-ocs-deviceset-thin-0-data-0m27q8

    4. Repeat these steps to delete the metadata associated with all the vault keys.

15. To ensure that OpenShift Container Storage is uninstalled completely, on the OpenShift Container Platform Web Console,

    1. Click Storage.
    2. Verify that Overview no longer appears under Storage.

Procedure

1. List the pods and PVCs that are currently running in the openshift-monitoring namespace.

   $ oc get pod,pvc -n openshift-monitoring
   NAME                           READY   STATUS    RESTARTS   AGE
   pod/alertmanager-main-0         3/3     Running   0          8d
   pod/alertmanager-main-1         3/3     Running   0          8d
   pod/alertmanager-main-2         3/3     Running   0          8d
   pod/cluster-monitoring-
   operator-84457656d-pkrxm        1/1     Running   0          8d
   pod/grafana-79ccf6689f-2ll28    2/2     Running   0          8d
   pod/kube-state-metrics-
   7d86fb966-rvd9w                 3/3     Running   0          8d
   pod/node-exporter-25894         2/2     Running   0          8d
   pod/node-exporter-4dsd7         2/2     Running   0          8d
   pod/node-exporter-6p4zc         2/2     Running   0          8d
   pod/node-exporter-jbjvg         2/2     Running   0          8d
   pod/node-exporter-jj4t5         2/2     Running   0          6d18h
   pod/node-exporter-k856s         2/2     Running   0          6d18h
   pod/node-exporter-rf8gn         2/2     Running   0          8d
   pod/node-exporter-rmb5m         2/2     Running   0          6d18h
   pod/node-exporter-zj7kx         2/2     Running   0          8d
   pod/openshift-state-metrics-
   59dbd4f654-4clng                3/3     Running   0          8d
   pod/prometheus-adapter-
   5df5865596-k8dzn                1/1     Running   0          7d23h
   pod/prometheus-adapter-
   5df5865596-n2gj9                1/1     Running   0          7d23h
   pod/prometheus-k8s-0            6/6     Running   1          8d
   pod/prometheus-k8s-1            6/6     Running   1          8d
   pod/prometheus-operator-
   55cfb858c9-c4zd9                1/1     Running   0          6d21h
   pod/telemeter-client-
   78fc8fc97d-2rgfp                3/3     Running   0          8d
   
   NAME                                                              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
   persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-0   Bound    pvc-0d519c4f-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
   persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-1   Bound    pvc-0d5a9825-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
   persistentvolumeclaim/my-alertmanager-claim-alertmanager-main-2   Bound    pvc-0d6413dc-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
   persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-0        Bound    pvc-0b7c19b0-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d
   persistentvolumeclaim/my-prometheus-claim-prometheus-k8s-1        Bound    pvc-0b8aed3f-15a5-11ea-baa0-026d231574aa   40Gi       RWO            ocs-storagecluster-ceph-rbd   8d

2. Edit the monitoring configmap.

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

3. Remove any config sections that reference the OpenShift Container Storage storage classes as shown in the following example and save it.

   Before editing

   . . . apiVersion: v1 data: config.yaml: | alertmanagerMain: volumeClaimTemplate: metadata: name: my-alertmanager-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-storagecluster-ceph-rbd prometheusK8s: volumeClaimTemplate: metadata: name: my-prometheus-claim spec: resources: requests: storage: 40Gi storageClassName: ocs-storagecluster-ceph-rbd kind: ConfigMap metadata: creationTimestamp: "2019-12-02T07:47:29Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "22110" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: fd6d988b-14d7-11ea-84ff-066035b9efa8 . . .

   After editing

   . . . apiVersion: v1 data: config.yaml: | kind: ConfigMap metadata: creationTimestamp: "2019-11-21T13:07:05Z" name: cluster-monitoring-config namespace: openshift-monitoring resourceVersion: "404352" selfLink: /api/v1/namespaces/openshift-monitoring/configmaps/cluster-monitoring-config uid: d12c796a-0c5f-11ea-9832-063cd735b81c . . .

   In this example, alertmanagerMain and prometheusK8s monitoring components are using the OpenShift Container Storage PVCs.

4. Delete relevant PVCs. Make sure you delete all the PVCs that are consuming the storage classes.

   $ oc delete -n openshift-monitoring pvc <pvc-name> --wait=true --timeout=5m

Procedure

1. Edit the configs.imageregistry.operator.openshift.io object and remove the content in the storage section.

   $ oc edit configs.imageregistry.operator.openshift.io

   Before editing

   . . . storage: pvc: claim: registry-cephfs-rwx-pvc . . .

   After editing

   . . . storage: emptyDir: {} . . .

   In this example, the PVC is called registry-cephfs-rwx-pvc, which is now safe to delete.

2. Delete the PVC.

   $ oc delete pvc <pvc-name> -n openshift-image-registry --wait=true --timeout=5m

Procedure

1. Remove the ClusterLogging instance in the namespace.

   $ oc delete clusterlogging instance -n openshift-logging --wait=true --timeout=5m

   The PVCs in the openshift-logging namespace are now safe to delete.

2. Delete PVCs.

   $ oc delete pvc <pvc-name> -n openshift-logging --wait=true --timeout=5m