Managing hybrid and multicloud resources

Procedure

1. From the MCG command-line interface, run the following command:

   noobaa backingstore create aws-s3 <backingstore_name> --access-key=<AWS ACCESS KEY> --secret-key=<AWS SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage

   Copy to Clipboard Toggle word wrap

1. Replace <backingstore_name> with the name of the backingstore.
2. Replace <AWS ACCESS KEY> and <AWS SECRET ACCESS KEY> with an AWS access key ID and secret access key you created for this purpose.

3. Replace <bucket-name> with an existing AWS bucket name. This argument tells the MCG which bucket to use as a target bucket for its backing store, and subsequently, data storage and administration.

   The output will be similar to the following:

   INFO[0001] ✅ Exists: NooBaa "noobaa"
   INFO[0002] ✅ Created: BackingStore "aws-resource"
   INFO[0002] ✅ Created: Secret "backing-store-secret-aws-resource"

   Copy to Clipboard Toggle word wrap

1. Create a secret with the credentials:

   apiVersion: v1
   kind: Secret
   metadata:
     name: <backingstore-secret-name>
     namespace: openshift-storage
   type: Opaque
   data:
     AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
     AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>

   Copy to Clipboard Toggle word wrap
   1. You must supply and encode your own AWS access key ID and secret access key using Base64, and use the results in place of <AWS ACCESS KEY ID ENCODED IN BASE64> and <AWS SECRET ACCESS KEY ENCODED IN BASE64>.
   2. Replace <backingstore-secret-name> with a unique name.

2. Apply the following YAML for a specific backing store:

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: bs
     namespace: openshift-storage
   spec:
     awsS3:
       secret:
         name: <backingstore-secret-name>
         namespace: openshift-storage
       targetBucket: <bucket-name>
     type: aws-s3

   Copy to Clipboard Toggle word wrap
   1. Replace <bucket-name> with an existing AWS bucket name. This argument tells the MCG which bucket to use as a target bucket for its backing store, and subsequently, data storage and administration.
   2. Replace <backingstore-secret-name> with the name of the secret created in the previous step.

Procedure

1. From the MCG command-line interface, run the following command:

   noobaa backingstore create ibm-cos <backingstore_name> --access-key=<IBM ACCESS KEY> --secret-key=<IBM SECRET ACCESS KEY> --endpoint=<IBM COS ENDPOINT> --target-bucket <bucket-name> -n openshift-storage

   Copy to Clipboard Toggle word wrap
   1. Replace <backingstore_name> with the name of the backingstore.

   2. Replace <IBM ACCESS KEY>, <IBM SECRET ACCESS KEY>, <IBM COS ENDPOINT> with an IBM access key ID, secret access key and the appropriate regional endpoint that corresponds to the location of the existing IBM bucket.

      To generate the above keys on IBM cloud, you must include HMAC credentials while creating the service credentials for your target bucket.

   3. Replace <bucket-name> with an existing IBM bucket name. This argument tells the MCG which bucket to use as a target bucket for its backing store, and subsequently, data storage and administration.

      The output will be similar to the following:

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "ibm-resource"
      INFO[0002] ✅ Created: Secret "backing-store-secret-ibm-resource"

      Copy to Clipboard Toggle word wrap

1. Create a secret with the credentials:

   apiVersion: v1
   kind: Secret
   metadata:
     name: <backingstore-secret-name>
     namespace: openshift-storage
   type: Opaque
   data:
     IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
     IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>

   Copy to Clipboard Toggle word wrap
   1. You must supply and encode your own IBM COS access key ID and secret access key using Base64, and use the results in place of <IBM COS ACCESS KEY ID ENCODED IN BASE64> and <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>.
   2. Replace <backingstore-secret-name> with a unique name.

2. Apply the following YAML for a specific backing store:

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: bs
     namespace: openshift-storage
   spec:
     ibmCos:
       endpoint: <endpoint>
       secret:
         name: <backingstore-secret-name>
         namespace: openshift-storage
       targetBucket: <bucket-name>
     type: ibm-cos

   Copy to Clipboard Toggle word wrap
   1. Replace <bucket-name> with an existing IBM COS bucket name. This argument tells the MCG which bucket to use as a target bucket for its backing store, and subsequently, data storage and administration.
   2. Replace <endpoint> with a regional endpoint that corresponds to the location of the existing IBM bucket name. This argument tells Multicloud Object Gateway which endpoint to use for its backing store, and subsequently, data storage and administration.
   3. Replace <backingstore-secret-name> with the name of the secret created in the previous step.

Procedure

1. From the MCG command-line interface, run the following command:

   noobaa backingstore create azure-blob <backingstore_name> --account-key=<AZURE ACCOUNT KEY> --account-name=<AZURE ACCOUNT NAME> --target-blob-container <blob container name> -n openshift-storage

   Copy to Clipboard Toggle word wrap
   1. Replace <backingstore_name> with the name of the backingstore.
   2. Replace <AZURE ACCOUNT KEY> and <AZURE ACCOUNT NAME> with an AZURE account key and account name you created for this purpose.

   3. Replace <blob container name> with an existing Azure blob container name. This argument tells the MCG which bucket to use as a target bucket for its backing store, and subsequently, data storage and administration.

      The output will be similar to the following:

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "azure-resource"
      INFO[0002] ✅ Created: Secret "backing-store-secret-azure-resource"

      Copy to Clipboard Toggle word wrap

1. Create a secret with the credentials:

   apiVersion: v1
   kind: Secret
   metadata:
     name: <backingstore-secret-name>
   type: Opaque
   data:
     AccountName: <AZURE ACCOUNT NAME ENCODED IN BASE64>
     AccountKey: <AZURE ACCOUNT KEY ENCODED IN BASE64>

   Copy to Clipboard Toggle word wrap
   1. You must supply and encode your own Azure Account Name and Account Key using Base64, and use the results in place of <AZURE ACCOUNT NAME ENCODED IN BASE64> and <AZURE ACCOUNT KEY ENCODED IN BASE64>.
   2. Replace <backingstore-secret-name> with a unique name.

2. Apply the following YAML for a specific backing store:

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: bs
     namespace: openshift-storage
   spec:
     azureBlob:
       secret:
         name: <backingstore-secret-name>
         namespace: openshift-storage
       targetBlobContainer: <blob-container-name>
     type: azure-blob

   Copy to Clipboard Toggle word wrap
   1. Replace <blob-container-name> with an existing Azure blob container name. This argument tells the MCG which bucket to use as a target bucket for its backing store, and subsequently, data storage and administration.
   2. Replace <backingstore-secret-name> with the name of the secret created in the previous step.

Procedure

1. From the MCG command-line interface, run the following command:

   noobaa backingstore create google-cloud-storage <backingstore_name> --private-key-json-file=<PATH TO GCP PRIVATE KEY JSON FILE> --target-bucket <GCP bucket name> -n openshift-storage

   Copy to Clipboard Toggle word wrap
   1. Replace <backingstore_name> with the name of the backingstore.
   2. Replace <PATH TO GCP PRIVATE KEY JSON FILE> with a path to your GCP private key created for this purpose.

   3. Replace <GCP bucket name> with an existing GCP object storage bucket name. This argument tells the MCG which bucket to use as a target bucket for its backing store, and subsequently, data storage and administration.

      The output will be similar to the following:

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "google-gcp"
      INFO[0002] ✅ Created: Secret "backing-store-google-cloud-storage-gcp"

      Copy to Clipboard Toggle word wrap

1. Create a secret with the credentials:

   apiVersion: v1
   kind: Secret
   metadata:
     name: <backingstore-secret-name>
   type: Opaque
   data:
     GoogleServiceAccountPrivateKeyJson: <GCP PRIVATE KEY ENCODED IN BASE64>

   Copy to Clipboard Toggle word wrap
   1. You must supply and encode your own GCP service account private key using Base64, and use the results in place of <GCP PRIVATE KEY ENCODED IN BASE64>.
   2. Replace <backingstore-secret-name> with a unique name.

2. Apply the following YAML for a specific backing store:

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: bs
     namespace: openshift-storage
   spec:
     googleCloudStorage:
       secret:
         name: <backingstore-secret-name>
         namespace: openshift-storage
       targetBucket: <target bucket>
     type: google-cloud-storage

   Copy to Clipboard Toggle word wrap
   1. Replace <target bucket> with an existing Google storage bucket. This argument tells the MCG which bucket to use as a target bucket for its backing store, and subsequently, data storage and administration.
   2. Replace <backingstore-secret-name> with the name of the secret created in the previous step.

Procedure

1. From the MCG command-line interface, run the following command:

   Note

   This command must be run from within the openshift-storage namespace.

   noobaa backingstore create  pv-pool <backingstore_name> --num-volumes=<NUMBER OF VOLUMES>  --pv-size-gb=<VOLUME SIZE> --storage-class=<LOCAL STORAGE CLASS> -n openshift-storage

   Copy to Clipboard Toggle word wrap
   1. Replace <backingstore_name> with the name of the backingstore.
   2. Replace <NUMBER OF VOLUMES> with the number of volumes you would like to create. Note that increasing the number of volumes scales up the storage.
   3. Replace <VOLUME SIZE> with the required size, in GB, of each volume.

   4. Replace <LOCAL STORAGE CLASS> with the local storage class, recommended to use ocs-storagecluster-ceph-rbd.

      The output will be similar to the following:

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Exists: BackingStore "local-mcg-storage"

      Copy to Clipboard Toggle word wrap

1. Apply the following YAML for a specific backing store:

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: <backingstore_name>
     namespace: openshift-storage
   spec:
      pvPool:
       numVolumes: <NUMBER OF VOLUMES>
       resources:
         requests:
           storage: <VOLUME SIZE>
       storageClass: <LOCAL STORAGE CLASS>
     type: pv-pool

   Copy to Clipboard Toggle word wrap
   1. Replace <backingstore_name> with the name of the backingstore.
   2. Replace <NUMBER OF VOLUMES> with the number of volumes you would like to create. Note that increasing the number of volumes scales up the storage.
   3. Replace <VOLUME SIZE> with the required size, in GB, of each volume. Note that the letter G should remain.
   4. Replace <LOCAL STORAGE CLASS> with the local storage class, recommended to use ocs-storagecluster-ceph-rbd.

Procedure

1. Create a secret with the credentials:

   apiVersion: v1
   kind: Secret
   metadata:
     name: <namespacestore-secret-name>
     type: Opaque
   data:
     AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
     AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>

   Copy to Clipboard Toggle word wrap
   1. You must supply and encode your own AWS access key ID and secret access key using Base64, and use the results in place of <AWS ACCESS KEY ID ENCODED IN BASE64> and <AWS SECRET ACCESS KEY ENCODED IN BASE64>.
   2. Replace <namespacestore-secret-name> with a unique name.

2. Create a NamespaceStore resource using OpenShift Custom Resource Definitions (CRDs). A NamespaceStore represents underlying storage to be used as a read or write target for the data in the MCG namespace buckets. To create a NamespaceStore resource, apply the following YAML:

   apiVersion: noobaa.io/v1alpha1
   kind: NamespaceStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: <resource-name>
     namespace: openshift-storage
   spec:
     awsS3:
       secret:
         name: <namespacestore-secret-name>
         namespace: <namespace-secret>
       targetBucket: <target-bucket>
     type: aws-s3

   Copy to Clipboard Toggle word wrap
   1. Replace <resource-name> with the name you want to give to the resource.
   2. Replace <namespacestore-secret-name> with the secret created in step 1.
   3. Replace <namespace-secret> with the namespace where the secret can be found.
   4. Replace <target-bucket> with the target bucket you created for the NamespaceStore.

3. Create a namespace bucket class that defines a namespace policy for the namespace buckets. The namespace policy requires a type of either single or multi.

   • A namespace policy of type single requires the following configuration:

     apiVersion: noobaa.io/v1alpha1
     kind: BucketClass
     metadata:
       labels:
         app: noobaa
       name: <my-bucket-class>
       namespace: openshift-storage
     spec:
       namespacePolicy:
         type:
         single:
           resource: <resource>

     Copy to Clipboard Toggle word wrap
     • Replace <my-bucket-class> with a unique namespace bucket class name.
     • Replace <resource> with the name of a single namespace-store that defines the read and write target of the namespace bucket.

   • A namespace policy of type multi requires the following configuration:

     apiVersion: noobaa.io/v1alpha1
     
     kind: BucketClass
     metadata:
       labels:
         app: noobaa
       name: <my-bucket-class>
       namespace: openshift-storage
     spec:
       namespacePolicy:
         type: Multi
         multi:
           writeResource: <write-resource>
           readResources:
           - <read-resources>
           - <read-resources>

     Copy to Clipboard Toggle word wrap
     • Replace <my-bucket-class> with a unique bucket class name.
     • Replace <write-resource> with the name of a single namespace-store that defines the write target of the namespace bucket.
     • Replace <read-resources> with a list of the names of the namespace-stores that defines the read targets of the namespace bucket.

4. Apply the following YAML to create a bucket using an Object Bucket Class (OBC) resource that uses the bucket class defined in step 2.

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     name: <resource-name>
     namespace: openshift-storage
   spec:
     generateBucketName: <my-bucket>
     storageClassName: openshift-storage.noobaa.io
     additionalConfig:
       bucketclass: <my-bucket-class>

   Copy to Clipboard Toggle word wrap
   1. Replace <resource-name> with the name you want to give to the resource.
   2. Replace <my-bucket> with the name you want to give to the bucket.
   3. Replace <my-bucket-class> with the bucket class created in the previous step.

Procedure

1. Create a secret with the credentials:

   apiVersion: v1
   kind: Secret
   metadata:
     name: <namespacestore-secret-name>
     type: Opaque
   data:
     IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
     IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>

   Copy to Clipboard Toggle word wrap
   1. You must supply and encode your own IBM COS access key ID and secret access key using Base64, and use the results in place of <IBM COS ACCESS KEY ID ENCODED IN BASE64> and <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>.
   2. Replace <namespacestore-secret-name> with a unique name.

2. Create a NamespaceStore resource using OpenShift Custom Resource Definitions (CRDs). A NamespaceStore represents underlying storage to be used as a read or write target for the data in the MCG namespace buckets. To create a NamespaceStore resource, apply the following YAML:

   apiVersion: noobaa.io/v1alpha1
   kind: NamespaceStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: bs
     namespace: openshift-storage
   spec:
     s3Compatible:
       endpoint: <IBM COS ENDPOINT>
       secret:
         name: <namespacestore-secret-name>
         namespace: <namespace-secret>
       signatureVersion: v2
       targetBucket: <target-bucket>
     type: ibm-cos

   Copy to Clipboard Toggle word wrap
   1. Replace <IBM COS ENDPOINT> with the appropriate IBM COS endpoint.
   2. Replace <namespacestore-secret-name> with the secret created in step 1.
   3. Replace <namespace-secret> with the namespace where the secret can be found.
   4. Replace <target-bucket> with the target bucket you created for the NamespaceStore.

3. Create a namespace bucket class that defines a namespace policy for the namespace buckets. The namespace policy requires a type of either single or multi.

   • A namespace policy of type single requires the following configuration:

     apiVersion: noobaa.io/v1alpha1
     kind: BucketClass
     metadata:
       labels:
         app: noobaa
       name: <my-bucket-class>
       namespace: openshift-storage
     spec:
       namespacePolicy:
         type:
         single:
           resource: <resource>

     Copy to Clipboard Toggle word wrap
     • Replace <my-bucket-class> with a unique namespace bucket class name.
     • Replace <resource> with a the name of a single namespace-store that defines the read and write target of the namespace bucket.

   • A namespace policy of type multi requires the following configuration:

     apiVersion: noobaa.io/v1alpha1
     kind: BucketClass
     metadata:
       labels:
         app: noobaa
       name: <my-bucket-class>
       namespace: openshift-storage
     spec:
       namespacePolicy:
         type: Multi
         multi:
           writeResource: <write-resource>
           readResources:
           - <read-resources>
           - <read-resources>

     Copy to Clipboard Toggle word wrap
     • Replace <my-bucket-class> with a unique bucket class name.
     • Replace <write-resource> with the name of a single namespace-store that defines the write target of the namespace bucket.
     • Replace <read-resources> with a list of the names of namespace-stores that defines the read targets of the namespace bucket.

4. Apply the following YAML to create a bucket using an Object Bucket Class (OBC) resource that uses the bucket class defined in step 2.

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     name: <resource-name>
     namespace: openshift-storage
   spec:
     generateBucketName: <my-bucket>
     storageClassName: openshift-storage.noobaa.io
     additionalConfig:
       bucketclass: <my-bucket-class>

   Copy to Clipboard Toggle word wrap
   1. Replace <resource-name> with the name you want to give to the resource.
   2. Replace <my-bucket> with the name you want to give to the bucket.
   3. Replace <my-bucket-class> with the bucket class created in the previous step.

Procedure

1. Create a NamespaceStore resource. A NamespaceStore represents an underlying storage to be used as a read or write target for the data in MCG namespace buckets. From the MCG command-line interface, run the following command:

   noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage

   Copy to Clipboard Toggle word wrap
   1. Replace <namespacestore> with the name of the NamespaceStore.
   2. Replace <AWS ACCESS KEY> and <AWS SECRET ACCESS KEY> with an AWS access key ID and secret access key you created for this purpose.
   3. Replace <bucket-name> with an existing AWS bucket name. This argument tells the MCG which bucket to use as a target bucket for its backing store, and subsequently, data storage and administration.

2. Create a namespace bucket class that defines a namespace policy for the namespace buckets. The namespace policy requires a type of either single or multi.

   • Run the following command to create a namespace bucket class with a namespace policy of type single:

     noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage

     Copy to Clipboard Toggle word wrap
     • Replace <resource-name> with the name you want to give the resource.
     • Replace <my-bucket-class> with a unique bucket class name.
     • Replace <resource> with a single namespace-store that defines the read and write target of the namespace bucket.

   • Run the following command to create a namespace bucket class with a namespace policy of type multi:

     noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage

     Copy to Clipboard Toggle word wrap
     • Replace <resource-name> with the name you want to give the resource.
     • Replace <my-bucket-class> with a unique bucket class name.
     • Replace <write-resource> with a single namespace-store that defines the write target of the namespace bucket.
     • Replace <read-resources> with a list of namespace-stores separated by commas that defines the read targets of the namespace bucket.

3. Run the following command to create a bucket using an Object Bucket Class (OBC) resource that uses the bucket class defined in step 2.

   noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>

   Copy to Clipboard Toggle word wrap
   1. Replace <bucket-name> with a bucket name of your choice.
   2. Replace <custom-bucket-class> with the name of the bucket class created in step 2.

Procedure

1. Create a NamespaceStore resource. A NamespaceStore represents an underlying storage to be used as a read or write target for the data in MCG namespace buckets. From the MCG command-line interface, run the following command:

   noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage

   Copy to Clipboard Toggle word wrap
   1. Replace <namespacestore> with the name of the NamespaceStore.
   2. Replace <IBM ACCESS KEY>, <IBM SECRET ACCESS KEY>, <IBM COS ENDPOINT> with an IBM access key ID, secret access key and the appropriate regional endpoint that corresponds to the location of the existing IBM bucket.
   3. Replace <bucket-name> with an existing IBM bucket name. This argument tells the MCG which bucket to use as a target bucket for its backing store, and subsequently, data storage and administration.

2. Create a namespace bucket class that defines a namespace policy for the namespace buckets. The namespace policy requires a type of either single or multi.

   • Run the following command to create a namespace bucket class with a namespace policy of type single:

     noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage

     Copy to Clipboard Toggle word wrap
     • Replace <resource-name> with the name you want to give the resource.
     • Replace <my-bucket-class> with a unique bucket class name.
     • Replace <resource> with a single namespace-store that defines the read and write target of the namespace bucket.

   • Run the following command to create a namespace bucket class with a namespace policy of type multi:

     noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage

     Copy to Clipboard Toggle word wrap
     • Replace <resource-name> with the name you want to give the resource.
     • Replace <my-bucket-class> with a unique bucket class name.
     • Replace <write-resource> with a single namespace-store that defines the write target of the namespace bucket.
     • Replace <read-resources> with a list of namespace-stores separated by commas that defines the read targets of the namespace bucket.

3. Run the following command to create a bucket using an Object Bucket Class (OBC) resource that uses the bucket class defined in step 2.

   noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>

   Copy to Clipboard Toggle word wrap
   1. Replace <bucket-name> with a bucket name of your choice.
   2. Replace <custom-bucket-class> with the name of the bucket class created in step 2.

Procedure

1. Log into the OpenShift Web Console.
2. Click Storage → Data Foundation.
3. Click the NamespaceStore tab to create NamespaceStore resources to be used in the namespace bucket.
4. Click Create namespacestore.
5. Enter a name for the NamespaceStore.
6. Choose Filesystem as the provider.
7. Choose the Persistent volume claim.

8. Enter a folder name.

   If the folder name exists, then that folder is used to create the NamespaceStore or else a folder with that name is created.

9. Click Create.
10. Verify the NamespaceStore is in the Ready state.

Procedure

1. Display the application namespace with scc:

   $ oc get ns <application_namespace> -o yaml | grep scc

   Copy to Clipboard Toggle word wrap

   <application_namespace>

   Specify the name of the application namespace.

   Example 5.1. Example

   $ oc get ns testnamespace -o yaml | grep scc

   Copy to Clipboard Toggle word wrap

   Example 5.2. Example output

   openshift.io/sa.scc.mcs: s0:c26,c5
   openshift.io/sa.scc.supplemental-groups: 1000660000/10000
   openshift.io/sa.scc.uid-range: 1000660000/10000

   Copy to Clipboard Toggle word wrap

2. Navigate into the application namespace:

   $ oc project <application_namespace>

   Copy to Clipboard Toggle word wrap

   Example 5.3. Example

   $ oc project testnamespace

   Copy to Clipboard Toggle word wrap

3. Ensure that a ReadWriteMany (RWX) PVC is mounted on the pod that you want to consume from the noobaa S3 endpoint using the MCG NSFS feature:

   $ oc get pvc

   Copy to Clipboard Toggle word wrap

   Example 5.4. Example output

   NAME                                               STATUS VOLUME
   CAPACITY ACCESS MODES STORAGECLASS              AGE
   cephfs-write-workload-generator-no-cache-pv-claim  Bound  pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a
   10Gi     RWX          ocs-storagecluster-cephfs 12s

   Copy to Clipboard Toggle word wrap

   $ oc get pod

   Copy to Clipboard Toggle word wrap

   Example 5.5. Example output

   NAME                                                READY   STATUS              RESTARTS   AGE
   cephfs-write-workload-generator-no-cache-1-cv892    1/1     Running             0          11s

   Copy to Clipboard Toggle word wrap

4. Check the mount point of the Persistent Volume (PV) inside your pod.

   1. Get the volume name of the PV from the pod:

      $ oc get pods <pod_name> -o jsonpath='{.spec.volumes[]}'

      Copy to Clipboard Toggle word wrap

      <pod_name>

      Specify the name of the pod.

      Example 5.6. Example

      $ oc get pods cephfs-write-workload-generator-no-cache-1-cv892 -o jsonpath='{.spec.volumes[]}'

      Copy to Clipboard Toggle word wrap

      Example 5.7. Example output

      {"name":"app-persistent-storage","persistentVolumeClaim":{"claimName":"cephfs-write-workload-generator-no-cache-pv-claim"}}

      Copy to Clipboard Toggle word wrap

      In this example, the name of the volume for the PVC is cephfs-write-workload-generator-no-cache-pv-claim.

   2. List all the mounts in the pod, and check for the mount point of the volume that you identified in the previous step:

      $ oc get pods <pod_name> -o jsonpath='{.spec.containers[].volumeMounts}'

      Copy to Clipboard Toggle word wrap

      Example 5.8. Example

      $ oc get pods cephfs-write-workload-generator-no-cache-1-cv892 -o jsonpath='{.spec.containers[].volumeMounts}'

      Copy to Clipboard Toggle word wrap

      Example 5.9. Example output

      [{"mountPath":"/mnt/pv","name":"app-persistent-storage"},{"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount","name":"kube-api-access-8tnc5","readOnly":true}]

      Copy to Clipboard Toggle word wrap

5. Confirm the mount point of the RWX PV in your pod:

   $ oc exec -it <pod_name> -- df <mount_path>

   Copy to Clipboard Toggle word wrap

   <mount_path>

   Specify the path to the mount point that you identified in the previous step.

   Example 5.10. Example

   $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- df /mnt/pv

   Copy to Clipboard Toggle word wrap

   Example 5.11. Example output

   main
   Filesystem
   1K-blocks Used Available  Use%  Mounted on
   172.30.202.87:6789,172.30.120.254:6789,172.30.77.247:6789:/volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c
   10485760  0    10485760   0%    /mnt/pv

   Copy to Clipboard Toggle word wrap

6. Ensure that the UID and SELinux labels are the same as the ones that the legacy namespace uses:

   $ oc exec -it <pod_name> -- ls -latrZ <mount_path>

   Copy to Clipboard Toggle word wrap

   Example 5.12. Example

   $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- ls -latrZ /mnt/pv/

   Copy to Clipboard Toggle word wrap

   Example 5.13. Example output

   total 567
   drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5      2 May 25 06:35 .
   -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c26,c5 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log
   drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5     30 May 25 06:35 ..

   Copy to Clipboard Toggle word wrap

7. Get the information of the legacy application RWX PV that you want to make accessible from the openshift-storage namespace:

   $ oc get pv | grep <pv_name>

   Copy to Clipboard Toggle word wrap

   <pv_name>

   Specify the name of the PV.

   Example 5.14. Example

   $ oc get pv | grep pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a

   Copy to Clipboard Toggle word wrap

   Example 5.15. Example output

   pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a   10Gi       RWX            Delete           Bound    testnamespace/cephfs-write-workload-generator-no-cache-pv-claim   ocs-storagecluster-cephfs              47s

   Copy to Clipboard Toggle word wrap

8. Ensure that the PVC from the legacy application is accessible from the openshift-storage namespace so that one or more noobaa-endpoint pods can access the PVC.

   1. Find the values of the subvolumePath and volumeHandle from the volumeAttributes. You can get these values from the YAML description of the legacy application PV:

      $ oc get pv <pv_name> -o yaml

      Copy to Clipboard Toggle word wrap

      Example 5.16. Example

      $ oc get pv pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a -o yaml

      Copy to Clipboard Toggle word wrap

      Example 5.17. Example output

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        annotations:
          pv.kubernetes.io/provisioned-by: openshift-storage.cephfs.csi.ceph.com
        creationTimestamp: "2022-05-25T06:27:49Z"
        finalizers:
        - kubernetes.io/pv-protection
        name: pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a
        resourceVersion: "177458"
        uid: 683fa87b-5192-4ccf-af2f-68c6bcf8f500
      spec:
        accessModes:
        - ReadWriteMany
        capacity:
          storage: 10Gi
        claimRef:
          apiVersion: v1
          kind: PersistentVolumeClaim
          name: cephfs-write-workload-generator-no-cache-pv-claim
          namespace: testnamespace
          resourceVersion: "177453"
          uid: aa58fb91-c3d2-475b-bbee-68452a613e1a
        csi:
          controllerExpandSecretRef:
            name: rook-csi-cephfs-provisioner
            namespace: openshift-storage
          driver: openshift-storage.cephfs.csi.ceph.com
          nodeStageSecretRef:
            name: rook-csi-cephfs-node
            namespace: openshift-storage
          volumeAttributes:
            clusterID: openshift-storage
            fsName: ocs-storagecluster-cephfilesystem
            storage.kubernetes.io/csiProvisionerIdentity: 1653458225664-8081-openshift-storage.cephfs.csi.ceph.com
            subvolumeName: csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213
            subvolumePath: /volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c
          volumeHandle: 0001-0011-openshift-storage-0000000000000001-cc416d9e-dbf3-11ec-b286-0a580a810213
        persistentVolumeReclaimPolicy: Delete
        storageClassName: ocs-storagecluster-cephfs
        volumeMode: Filesystem
      status:
        phase: Bound

      Copy to Clipboard Toggle word wrap

   2. Use the subvolumePath and volumeHandle values that you identified in the previous step to create a new PV and PVC object in the openshift-storage namespace that points to the same CephFS volume as the legacy application PV:

      Example 5.18. Example YAML file

      $ cat << EOF >> pv-openshift-storage.yaml
      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: cephfs-pv-legacy-openshift-storage
      spec:
        storageClassName: ""
        accessModes:
        - ReadWriteMany
        capacity:
          storage: 10Gi     

      1

      
        csi:
          driver: openshift-storage.cephfs.csi.ceph.com
          nodeStageSecretRef:
            name: rook-csi-cephfs-node
            namespace: openshift-storage
          volumeAttributes:
          # Volume Attributes can be copied from the Source testnamespace PV
            "clusterID": "openshift-storage"
            "fsName": "ocs-storagecluster-cephfilesystem"
            "staticVolume": "true"
          # rootpath is the subvolumePath: you copied from the Source testnamespace PV
            "rootPath": /volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c
          volumeHandle: 0001-0011-openshift-storage-0000000000000001-cc416d9e-dbf3-11ec-b286-0a580a810213-clone   

      2

      
        persistentVolumeReclaimPolicy: Retain
        volumeMode: Filesystem
      ---
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: cephfs-pvc-legacy
        namespace: openshift-storage
      spec:
        storageClassName: ""
        accessModes:
        - ReadWriteMany
        resources:
          requests:
            storage: 10Gi     

      3

      
        volumeMode: Filesystem
        # volumeName should be same as PV name
        volumeName: cephfs-pv-legacy-openshift-storage
      EOF

      Copy to Clipboard Toggle word wrap

      1

      The storage capacity of the PV that you are creating in the openshift-storage namespace must be the same as the original PV.

      2

      The volume handle for the target PV that you create in openshift-storage needs to have a different handle than the original application PV, for example, add -clone at the end of the volume handle.

      3

      The storage capacity of the PVC that you are creating in the openshift-storage namespace must be the same as the original PVC.

   3. Create the PV and PVC in the openshift-storage namespace using the YAML file specified in the previous step:

      $ oc create -f <YAML_file>

      Copy to Clipboard Toggle word wrap

      <YAML_file>

      Specify the name of the YAML file.

      Example 5.19. Example

      $ oc create -f pv-openshift-storage.yaml

      Copy to Clipboard Toggle word wrap

      Example 5.20. Example output

      persistentvolume/cephfs-pv-legacy-openshift-storage created
      persistentvolumeclaim/cephfs-pvc-legacy created

      Copy to Clipboard Toggle word wrap

   4. Ensure that the PVC is available in the openshift-storage namespace:

      $ oc get pvc -n openshift-storage

      Copy to Clipboard Toggle word wrap

      Example 5.21. Example output

      NAME                                  STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
      cephfs-pvc-legacy                     Bound    cephfs-pv-legacy-openshift-storage         10Gi       RWX                                          14s

      Copy to Clipboard Toggle word wrap

   5. Navigate into the openshift-storage project:

      $ oc project openshift-storage

      Copy to Clipboard Toggle word wrap

      Example 5.22. Example output

      Now using project "openshift-storage" on server "https://api.cluster-5f6ng.5f6ng.sandbox65.opentlc.com:6443".

      Copy to Clipboard Toggle word wrap

   6. Create the NSFS namespacestore:

      $ noobaa namespacestore create nsfs <nsfs_namespacestore> --pvc-name='<cephfs_pvc_name>' --fs-backend='CEPH_FS'

      Copy to Clipboard Toggle word wrap

      <nsfs_namespacestore>

      Specify the name of the NSFS namespacestore.

      <cephfs_pvc_name>

      Specify the name of the CephFS PVC in the openshift-storage namespace.

      Example 5.23. Example

      $ noobaa namespacestore create nsfs legacy-namespace --pvc-name='cephfs-pvc-legacy' --fs-backend='CEPH_FS'

      Copy to Clipboard Toggle word wrap

   7. Ensure that the noobaa-endpoint pod restarts and that it successfully mounts the PVC at the NSFS namespacestore, for example, /nsfs/legacy-namespace mountpoint:

      $ oc exec -it <noobaa_endpoint_pod_name> -- df -h /nsfs/<nsfs_namespacestore>

      Copy to Clipboard Toggle word wrap

      <noobaa_endpoint_pod_name>

      Specify the name of the noobaa-endpoint pod.

      Example 5.24. Example

      $ oc exec -it noobaa-endpoint-5875f467f5-546c6 -- df -h /nsfs/legacy-namespace

      Copy to Clipboard Toggle word wrap

      Example 5.25. Example output

      Filesystem                                                                                                                                                Size  Used Avail Use% Mounted on
      172.30.202.87:6789,172.30.120.254:6789,172.30.77.247:6789:/volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c   10G     0   10G   0% /nsfs/legacy-namespace

      Copy to Clipboard Toggle word wrap

   8. Create a MCG user account:

      $ noobaa account create <user_account> --full_permission --allow_bucket_create=true --new_buckets_path='/' --nsfs_only=true --nsfs_account_config=true --gid <gid_number> --uid <uid_number> --default_resource='legacy-namespace'

      Copy to Clipboard Toggle word wrap

      <user_account>

      Specify the name of the MCG user account.

      <gid_number>

      Specify the GID number.

      <uid_number>

      Specify the UID number.

      Example 5.26. Example

      Important

      Use the same UID and GID as that of the legacy application. You can find it from the previous output.

      $ noobaa account create leguser --full_permission --allow_bucket_create=true --new_buckets_path='/' --nsfs_only=true --nsfs_account_config=true --gid 0 --uid 1000660000 --default_resource='legacy-namespace'

      Copy to Clipboard Toggle word wrap

   9. Create a MCG bucket.

      1. Create a dedicated folder for S3 inside the NSFS share on the CephFS PV and PVC of the legacy application pod:

         $ oc exec -it <pod_name> -- mkdir <mount_path>/nsfs

         Copy to Clipboard Toggle word wrap

         Example 5.27. Example

         $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- mkdir /mnt/pv/nsfs

         Copy to Clipboard Toggle word wrap

      2. Create the MCG bucket using the nsfs/ path:

         $ noobaa api bucket_api create_bucket '{
           "name": "<bucket_name>",
           "namespace":{
             "write_resource": { "resource": "<nsfs_namespacestore>", "path": "nsfs/" },
             "read_resources": [ { "resource": "<nsfs_namespacestore>", "path": "nsfs/" }]
           }
         }'

         Copy to Clipboard Toggle word wrap

         Example 5.28. Example

         $ noobaa api bucket_api create_bucket '{
           "name": "legacy-bucket",
           "namespace":{
             "write_resource": { "resource": "legacy-namespace", "path": "nsfs/" },
             "read_resources": [ { "resource": "legacy-namespace", "path": "nsfs/" }]
           }
         }'

         Copy to Clipboard Toggle word wrap

   10. Check the SELinux labels of the folders residing in the PVCs in the legacy application and openshift-storage namespaces:

       $ oc exec -it <noobaa_endpoint_pod_name> -n openshift-storage -- ls -ltraZ /nsfs/<nsfs_namespacstore>

       Copy to Clipboard Toggle word wrap

       Example 5.29. Example

       $ oc exec -it noobaa-endpoint-5875f467f5-546c6 -n openshift-storage -- ls -ltraZ /nsfs/legacy-namespace

       Copy to Clipboard Toggle word wrap

       Example 5.30. Example output

       total 567
       drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c0,c26      2 May 25 06:35 .
       -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c0,c26 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log
       drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c0,c26     30 May 25 06:35 ..

       Copy to Clipboard Toggle word wrap

       $ oc exec -it <pod_name> -- ls -latrZ <mount_path>

       Copy to Clipboard Toggle word wrap

       Example 5.31. Example

       $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- ls -latrZ /mnt/pv/

       Copy to Clipboard Toggle word wrap

       Example 5.32. Example output

       total 567
       drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5      2 May 25 06:35 .
       -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c26,c5 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log
       drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5     30 May 25 06:35 ..

       Copy to Clipboard Toggle word wrap

       In these examples, you can see that the SELinux labels are not the same which results in permission denied or access issues.

9. Ensure that the legacy application and openshift-storage pods use the same SELinux labels on the files.

   You can do this one of two ways:

   • Section 5.4.3.1, “Changing the default SELinux label on the legacy application project to match the one in the openshift-storage project”.
   • Section 5.4.3.2, “Modifying the SELinux label only for the deployment config that has the pod which mounts the legacy application PVC”.

10. Delete the NSFS namespacestore:

    1. Delete the MCG bucket:

       $ noobaa bucket delete <bucket_name>

       Copy to Clipboard Toggle word wrap

       Example 5.33. Example

       $ noobaa bucket delete legacy-bucket

       Copy to Clipboard Toggle word wrap

    2. Delete the MCG user account:

       $ noobaa account delete <user_account>

       Copy to Clipboard Toggle word wrap

       Example 5.34. Example

       $ noobaa account delete leguser

       Copy to Clipboard Toggle word wrap

    3. Delete the NSFS namespacestore:

       $ noobaa namespacestore delete <nsfs_namespacestore>

       Copy to Clipboard Toggle word wrap

       Example 5.35. Example

       $ noobaa namespacestore delete legacy-namespace

       Copy to Clipboard Toggle word wrap

11. Delete the PV and PVC:

    Important

    Before you delete the PV and PVC, ensure that the PV has a retain policy configured.

    $ oc delete pv <cephfs_pv_name>

    Copy to Clipboard Toggle word wrap

    $ oc delete pvc <cephfs_pvc_name>

    Copy to Clipboard Toggle word wrap

    <cephfs_pv_name>

    Specify the CephFS PV name of the legacy application.

    <cephfs_pvc_name>

    Specify the CephFS PVC name of the legacy application.

    Example 5.36. Example

    $ oc delete pv cephfs-pv-legacy-openshift-storage

    Copy to Clipboard Toggle word wrap

    $ oc delete pvc cephfs-pvc-legacy

    Copy to Clipboard Toggle word wrap