Deploying and managing OpenShift Data Foundation using Google Cloud

Procedure

1. Click Workloads → Pods from the OpenShift Web Console.

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

   Note

   If the Show default projects option is disabled, use the toggle button to list all the default projects.

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

3. Click the Running and Completed tabs to verify that the following pods are in Running and Completed state:

   Table 2.1. Pods corresponding to OpenShift Data Foundation cluster

   Component	Corresponding pods
   OpenShift Data Foundation Operator	ocs-operator-* (1 pod on any worker node) ocs-metrics-exporter-* (1 pod on any worker node) odf-operator-controller-manager-* (1 pod on any worker node) odf-console-* (1 pod on any worker node)
   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)
   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. In the OpenShift Web Console, click Storage → OpenShift Data Foundation.
2. In the Status card of the Overview tab, click Storage System and then click the storage system link from the pop up that appears.
3. In the Status card of the Block and File tab, verify that Storage Cluster has a green tick.
4. In the Details card, verify that the cluster information is displayed.

Procedure

1. In the OpenShift Web Console, click Storage → OpenShift Data Foundation.

2. In the Status card of the Overview tab, click Storage System and then click the storage system link from the pop up that appears.

   1. In the Status card of the Object tab, verify that both Object Service and Data Resiliency have a green tick.
   2. In the Details card, verify that the MCG information is displayed.

Procedure

1. Click Storage → Storage Classes from the left pane of the OpenShift Web Console.

2. Verify that the following storage classes are created with the OpenShift Data Foundation cluster creation:

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

1. Navigate to Storage → StorageClasses.
2. Click Create Storage Class.
3. Enter the storage class Name and Description.
4. Select either Delete or Retain for the Reclaim Policy. By default, Delete is selected.
5. Select either Immediate or WaitForFirstConsumer as the Volume binding mode. WaitForConsumer is set as the default option.
6. Select RBD Provisioner openshift-storage.rbd.csi.ceph.com which is the plugin used for provisioning the persistent volumes.
7. Select Storage Pool where the volume data is stored from the list or create a new pool.

8. Select the Enable encryption checkbox. There are two options available to set the KMS connection details:

   • Choose existing KMS connection: Select an existing KMS connection from the drop-down list. The list is populated from the the connection details available in the csi-kms-connection-details ConfigMap.

   • Create new KMS connection: This is applicable for vaulttokens only.

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

     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 Data Foundation.
        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.
     4. Click Save.
9. Click Create.

10. Edit the ConfigMap to add the VAULT_BACKEND or vaultBackend parameter if the HashiCorp Vault setup does not allow automatic detection of the Key/Value (KV) secret engine API version used by the backend path.

    Note

    VAULT_BACKEND or vaultBackend are optional parameters that has added to the configmap to specify the version of the KV secret engine API associated with the backend path. Ensure that the value matches the KV secret engine API version that is set for the backend path, otherwise it might result in a failure during persistent volume claim (PVC) creation.

    1. Identify the encryptionKMSID being used by the newly created storage class.

       1. On the OpenShift Web Console, navigate to Storage → Storage Classes.
       2. Click the Storage class name → YAML tab.

       3. Capture the encryptionKMSID being used by the storage class.

          Example:

          encryptionKMSID: 1-vault

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

    4. Edit the ConfigMap.

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

       2. Add the VAULT_BACKEND or vaultBackend parameter depending on the backend that is configured for the previously identified encryptionKMSID.

          You can assign kv for KV secret engine API, version 1 and kv-v2 for KV secret engine API, version 2.

          Example:

           kind: ConfigMap
           apiVersion: v1
           metadata:
             name: csi-kms-connection-details
           [...]
           data:
             1-vault: |-
               {
                 "KMS_PROVIDER": "vaulttokens",
                 "KMS_SERVICE_NAME": "1-vault",
                 [...]
                 "VAULT_BACKEND": "kv-v2"
               }
             2-vault: |-
               {
                 "encryptionKMSType": "vaulttenantsa",
                 [...]
                 "vaultBackend": "kv-v2"
               }

       3. Click Save

Procedure

1. Click Administration → Custom Resource Definitions from the left pane of the OpenShift Web Console.
2. On the Custom Resource Definitions page, click ClusterLogging.
3. On the Custom Resource Definition Overview page, select View Instances from the Actions menu or click the Instances Tab.

4. On the Cluster Logging page, click Create Cluster Logging.

   You might have to refresh the page to load the data.

5. In the YAML, replace the storageClassName with the storageclass that uses the provisioner openshift-storage.rbd.csi.ceph.com. In the example given below the name of the storageclass is ocs-storagecluster-ceph-rbd:

   apiVersion: "logging.openshift.io/v1"
   kind: "ClusterLogging"
   metadata:
     name: "instance"
     namespace: "openshift-logging"
   spec:
     managementState: "Managed"
     logStore:
       type: "elasticsearch"
       elasticsearch:
         nodeCount: 3
         storage:
           storageClassName: ocs-storagecluster-ceph-rbd
           size: 200G # Change as per your requirement
         redundancyPolicy: "SingleRedundancy"
     visualization:
       type: "kibana"
       kibana:
         replicas: 1
     curation:
       type: "curator"
       curator:
         schedule: "30 3 * * *"
     collection:
       logs:
         type: "fluentd"
         fluentd: {}

   If you have tainted the OpenShift Data Foundation nodes, you must add toleration to enable scheduling of the daemonset pods for logging.

   spec:
   [...]
     collection:
       logs:
         fluentd:
           tolerations:
           - effect: NoSchedule
             key: node.ocs.openshift.io/storage
             value: 'true'
         type: fluentd

6. Click Save.

Verification steps

1. Verify that the Persistent Volume Claims are bound to the elasticsearch pods.

   1. Go to Storage → Persistent Volume Claims.
   2. Set the Project dropdown to openshift-logging.

   3. Verify that Persistent Volume Claims are visible with a state of Bound, attached to elasticsearch-* pods.

      Figure 6.4. Cluster logging created and bound

      

2. Verify that the new cluster logging is being used.

   1. Click Workload → Pods.
   2. Set the Project to openshift-logging.
   3. Verify that the new elasticsearch-* pods appear with a state of Running.
   4. Click the new elasticsearch-* pod to view pod details.
   5. Scroll down to Volumes and verify that the elasticsearch volume has a Type that matches your new Persistent Volume Claim, for example, elasticsearch-elasticsearch-cdm-9r624biv-3.
   6. Click the Persistent Volume Claim name and verify the storage class name in the PersistentVolumeClaim Overview page.

Procedure

1. Navigate to Compute → Machine Sets.

2. On the machine set where you want to add nodes, select Edit Machine Count.

   1. Add the amount of nodes, and click Save.
   2. Click Compute → Nodes and confirm if the new node is in Ready state.

3. Apply the OpenShift Data Foundation label to the new node.

   1. For the new node, click Action menu (⋮) → Edit Labels.
   2. Add cluster.ocs.openshift.io/openshift-storage, and click Save.

1. Execute the following command and verify that the new node is present in the output:

   $ oc get nodes --show-labels | grep cluster.ocs.openshift.io/openshift-storage= |cut -d' ' -f1

2. Click Workloads → Pods, confirm that at least the following pods on the new node are in Running state:

   • csi-cephfsplugin-*
   • csi-rbdplugin-*

Procedure

1. In the OpenShift Web Console, click Storage → OpenShift Data Foundation.
2. Click the Backing Store tab.
3. Click Create Backing Store.

4. On the Create New Backing Store page, perform the following:

   1. Enter a Backing Store Name.
   2. Select a Provider.
   3. Select a Region.
   4. Enter an Endpoint. This is optional.

   5. Select a Secret from the drop-down list, or create your own secret. Optionally, you can Switch to Credentials view which lets you fill in the required secrets.

      For more information on creating an OCP secret, see the section Creating the secret in the Openshift Container Platform documentation.

      Each backingstore requires a different secret. For more information on creating the secret for a particular backingstore, see the Section 10.4.2, “Adding storage resources for hybrid or Multicloud using the MCG command line interface” and follow the procedure for the addition of storage resources using a YAML.

      Note

      This menu is relevant for all providers except Google Cloud and local PVC.

   6. Enter the Target bucket. The target bucket is a container storage that is hosted on the remote cloud service. It allows you to create a connection that tells the MCG that it can use this bucket for the system.
5. Click Create Backing Store.

Verification steps

1. In the OpenShift Web Console, click Storage → OpenShift Data Foundation.
2. Click the Backing Store tab to view all the backing stores.

Procedure

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

   noobaa backingstore create s3-compatible rgw-resource --access-key=<RGW ACCESS KEY> --secret-key=<RGW SECRET KEY> --target-bucket=<bucket-name> --endpoint=<RGW endpoint>

   1. To get the <RGW ACCESS KEY> and <RGW SECRET KEY>, run the following command using your RGW user secret name:

      oc get secret <RGW USER SECRET NAME> -o yaml -n openshift-storage

   2. Decode the access key ID and the access key from Base64 and keep them.
   3. Replace <RGW USER ACCESS KEY> and <RGW USER SECRET ACCESS KEY> with the appropriate, decoded data from the previous step.
   4. Replace <bucket-name> with an existing RGW 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.

   5. To get the <RGW endpoint>, see Accessing the RADOS Object Gateway S3 endpoint.

      The output will be similar to the following:

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

1. Create a CephObjectStore user. This also creates a secret containing the RGW credentials:

   apiVersion: ceph.rook.io/v1
   kind: CephObjectStoreUser
   metadata:
     name: <RGW-Username>
     namespace: openshift-storage
   spec:
     store: ocs-storagecluster-cephobjectstore
     displayName: "<Display-name>"

   1. Replace <RGW-Username> and <Display-name> with a unique username and display name.

2. Apply the following YAML for an S3-Compatible backing store:

   apiVersion: noobaa.io/v1alpha1
   kind: BackingStore
   metadata:
     finalizers:
     - noobaa.io/finalizer
     labels:
       app: noobaa
     name: <backingstore-name>
     namespace: openshift-storage
   spec:
     s3Compatible:
       endpoint: <RGW endpoint>
       secret:
         name: <backingstore-secret-name>
         namespace: openshift-storage
       signatureVersion: v4
       targetBucket: <RGW-bucket-name>
     type: s3-compatible

   1. Replace <backingstore-secret-name> with the name of the secret that was created with CephObjectStore in the previous step.
   2. Replace <bucket-name> with an existing RGW 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.
   3. To get the <RGW endpoint>, see Accessing the RADOS Object Gateway S3 endpoint.

Procedure

1. In the OpenShift Web Console, click Storage → OpenShift Data Foundation.
2. In the Storage Systems tab, select the storage system and then click Overview → Object tab.
3. Select the Multicloud Object Gateway link.

1. Select the Resources tab in the left, highlighted below. From the list that populates, select Add Cloud Resource.

   

2. Select Add new connection.

   

3. Select the relevant native cloud provider or S3 compatible option and fill in the details.

   

4. Select the newly created connection and map it to the existing bucket.

   
5. Repeat these steps to create as many backing stores as needed.

Procedure

1. In the OpenShift Web Console, click Storage → OpenShift Data Foundation.
2. Click the Bucket Class tab.
3. Click Create Bucket Class.

4. On the Create new Bucket Class page, perform the following:

   1. Select the bucket class type and enter a bucket class name.

      1. Select the BucketClass type. Choose one of the following options:

         • Standard: data will be consumed by a Multicloud Object Gateway (MCG), deduped, compressed and encrypted.

         • Namespace: data is stored on the NamespaceStores without performing de-duplication, compression or encryption.

           By default, Standard is selected.

      2. Enter a Bucket Class Name.
      3. Click Next.

   2. In Placement Policy, select Tier 1 - Policy Type and click Next. You can choose either one of the options as per your requirements.

      • Spread allows spreading of the data across the chosen resources.
      • Mirror allows full duplication of the data across the chosen resources.
      • Click Add Tier to add another policy tier.

   3. Select at least one Backing Store resource from the available list if you have selected Tier 1 - Policy Type as Spread and click Next. Alternatively, you can also create a new backing store.

      Note

      You need to select at least 2 backing stores when you select Policy Type as Mirror in previous step.

   4. Review and confirm Bucket Class settings.
   5. Click Create Bucket Class.

Verification steps

1. In the OpenShift Web Console, click Storage → OpenShift Data Foundation.
2. Click the Bucket Class tab and search the new Bucket Class.

Procedure

1. In the OpenShift Web Console, click Storage → OpenShift Data Foundation.
2. Click the Bucket Class tab.
3. Click the Action Menu (⋮) next to the Bucket class you want to edit.
4. Click Edit Bucket Class.
5. You are redirected to the YAML file, make the required changes in this file and click Save.

Procedure

1. In the OpenShift Web Console, click Storage → OpenShift Data Foundation.
2. Click the Bucket Class tab.

3. Click the Action Menu (⋮) next to the Bucket class you want to edit.

   
4. Click Edit Bucket Class Resources.

5. On the Edit Bucket Class Resources page, edit the bucket class resources either by adding a backing store to the bucket class or by removing a backing store from the bucket class. You can also edit bucket class resources created with one or two tiers and different placement policies.

   • To add a backing store to the bucket class, select the name of the backing store.

   • To remove a backing store from the bucket class, clear the name of the backing store.

     
6. Click Save.

Procedure

1. Log into the OpenShift Web Console.
2. Click Storage → OpenShift Data Foundation.

3. Click the Namespace Store tab to create a namespacestore resources to be used in the namespace bucket.

   1. Click Create namespace store.
   2. Enter a namespacestore name.
   3. Choose a provider.
   4. Choose a region.
   5. Either select an existing secret, or click Switch to credentials to create a secret by entering a secret key and secret access key.
   6. Choose a target bucket.
   7. Click Create.
   8. Verify the namespacestore is in the Ready state.
   9. Repeat these steps until you have the desired amount of resources.

4. Click the Bucket Class tab → Create a new Bucket Class.

   1. Select the Namespace radio button.
   2. Enter a Bucket Class name.
   3. Add a description (optional).
   4. Click Next.
5. Choose a namespace policy type for your namespace bucket, and then click Next.

6. Select the target resource(s).

   • If your namespace policy type is Single, you need to choose a read resource.
   • If your namespace policy type is Multi, you need to choose read resources and a write resource.
   • If your namespace policy type is Cache, you need to choose a Hub namespace store that defines the read and write target of the namespace bucket.
7. Click Next.
8. Review your new bucket class, and then click Create Bucketclass.
9. On the BucketClass page, verify that your newly created resource is in the Created phase.
10. In the OpenShift Web Console, click Storage → OpenShift Data Foundation.
11. In the Status card, click Storage System and click the storage system link from the pop up that appears.
12. In the Object tab, click Multicloud Object Gateway → Buckets → Namespace Buckets tab .

13. Click Create Namespace Bucket.

    1. On the Choose Name tab, specify a Name for the namespace bucket and click Next.

    2. On the Set Placement tab:

       1. Under Read Policy, select the checkbox for each namespace resource created in step 5 that the namespace bucket should read data from.
       2. If the namespace policy type you are using is Multi, then Under Write Policy, specify which namespace resource the namespace bucket should write data to.
       3. Click Next.
    3. Click Create.

1. From the Multicloud Object Gateway (MCG) command-line interface, run the following command to create a bucket class with a mirroring policy:

   $ noobaa bucketclass create placement-bucketclass mirror-to-aws --backingstores=azure-resource,aws-resource --placement Mirror

2. Set the newly created bucket class to a new bucket claim, generating a new bucket that will be mirrored between two locations:

   $ noobaa obc create  mirrored-bucket --bucketclass=mirror-to-aws

1. Apply the following YAML. This YAML is a hybrid example that mirrors data between local Ceph storage and AWS:

   apiVersion: noobaa.io/v1alpha1
   kind: BucketClass
   metadata:
     labels:
       app: noobaa
     name: <bucket-class-name>
     namespace: openshift-storage
   spec:
     placementPolicy:
       tiers:
       - backingStores:
         - <backing-store-1>
         - <backing-store-2>
         placement: Mirror

2. Add the following lines to your standard Object Bucket Claim (OBC):

   additionalConfig:
     bucketclass: mirror-to-aws

   For more information about OBCs, see Section 10.8, “Object Bucket Claim”.

1. In the OpenShift Web Console, click Storage → OpenShift Data Foundation.
2. In the Status card, click Storage System and click the storage system link from the pop up that appears.
3. In the Object tab, click the Multicloud Object Gateway link.

4. On the NooBaa page, click the buckets icon on the left side. You can see a list of your buckets:

   
5. Click the bucket you want to update.

6. Click Edit Tier 1 Resources:

   

7. Select Mirror and check the relevant resources you want to use for this bucket. In the following example, the data between noobaa-default-backing-store which is on RGW and AWS-backingstore which is on AWS is mirrored:

   
8. Click Save.

1. Create the bucket policy in JSON format. See the following example:

   {
       "Version": "NewVersion",
       "Statement": [
           {
               "Sid": "Example",
               "Effect": "Allow",
               "Principal": [
                       "john.doe@example.com"
               ],
               "Action": [
                   "s3:GetObject"
               ],
               "Resource": [
                   "arn:aws:s3:::john_bucket"
               ]
           }
       ]
   }

   There are many available elements for bucket policies with regard to access permissions.

   For details on these elements and examples of how they can be used to control the access permissions, see AWS Access Policy Language Overview.

   For more examples of bucket policies, see AWS Bucket Policy Examples.

   Instructions for creating S3 users can be found in Section 10.7.3, “Creating an AWS S3 user in the Multicloud Object Gateway”.

2. Using AWS S3 client, use the put-bucket-policy command to apply the bucket policy to your S3 bucket:

   # aws --endpoint ENDPOINT --no-verify-ssl s3api put-bucket-policy --bucket MyBucket --policy BucketPolicy

   1. Replace ENDPOINT with the S3 endpoint.
   2. Replace MyBucket with the bucket to set the policy on.
   3. Replace BucketPolicy with the bucket policy JSON file.

   4. Add --no-verify-ssl if you are using the default self signed certificates.

      For example:

      # aws --endpoint https://s3-openshift-storage.apps.gogo44.noobaa.org --no-verify-ssl s3api put-bucket-policy -bucket MyBucket --policy file://BucketPolicy

      For more information on the put-bucket-policy command, see the AWS CLI Command Reference for put-bucket-policy.

      Note

      The principal element specifies the user that is allowed or denied access to a resource, such as a bucket. Currently, Only NooBaa accounts can be used as principals. In the case of object bucket claims, NooBaa automatically create an account obc-account.<generated bucket name>@noobaa.io.

      Note

      Bucket policy conditions are not supported.

Procedure

1. In the OpenShift Web Console, click Storage → OpenShift Data Foundation.
2. In the Status card, click Storage System and click the storage system link from the pop up that appears.
3. In the Object tab, click the Multicloud Object Gateway link.

4. Under the Accounts tab, click Create Account.

   

5. Select S3 Access Only, provide the Account Name, for example, john.doe@example.com. Click Next.

   

6. Select S3 default placement, for example, noobaa-default-backing-store. Select Buckets Permissions. A specific bucket or all buckets can be selected. Click Create.

   

Procedure

1. Add the following lines to your application YAML:

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     name: <obc-name>
   spec:
     generateBucketName: <obc-bucket-name>
     storageClassName: openshift-storage.noobaa.io

   These lines are the OBC itself.

   1. Replace <obc-name> with the a unique OBC name.
   2. Replace <obc-bucket-name> with a unique bucket name for your OBC.

2. You can add more lines to the YAML file to automate the use of the OBC. The example below is the mapping between the bucket claim result, which is a configuration map with data and a secret with the credentials. This specific job claims the Object Bucket from NooBaa, which creates a bucket and an account.

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: testjob
   spec:
     template:
       spec:
         restartPolicy: OnFailure
         containers:
           - image: <your application image>
             name: test
             env:
               - name: BUCKET_NAME
                 valueFrom:
                   configMapKeyRef:
                     name: <obc-name>
                     key: BUCKET_NAME
               - name: BUCKET_HOST
                 valueFrom:
                   configMapKeyRef:
                     name: <obc-name>
                     key: BUCKET_HOST
               - name: BUCKET_PORT
                 valueFrom:
                   configMapKeyRef:
                     name: <obc-name>
                     key: BUCKET_PORT
               - name: AWS_ACCESS_KEY_ID
                 valueFrom:
                   secretKeyRef:
                     name: <obc-name>
                     key: AWS_ACCESS_KEY_ID
               - name: AWS_SECRET_ACCESS_KEY
                 valueFrom:
                   secretKeyRef:
                     name: <obc-name>
                     key: AWS_SECRET_ACCESS_KEY

   1. Replace all instances of <obc-name> with your OBC name.
   2. Replace <your application image> with your application image.

3. Apply the updated YAML file:

   # oc apply -f <yaml.file>

   Replace <yaml.file> with the name of your YAML file.

4. To view the new configuration map, run the following:

   # oc get cm <obc-name> -o yaml

   Replace obc-name with the name of your OBC.

   You can expect the following environment variables in the output:

   • BUCKET_HOST - Endpoint to use in the application.

   • BUCKET_PORT - The port available for the application.

     • The port is related to the BUCKET_HOST. For example, if the BUCKET_HOST is https://my.example.com, and the BUCKET_PORT is 443, the endpoint for the object service would be https://my.example.com:443.
   • BUCKET_NAME - Requested or generated bucket name.
   • AWS_ACCESS_KEY_ID - Access key that is part of the credentials.
   • AWS_SECRET_ACCESS_KEY - Secret access key that is part of the credentials.

Procedure

1. Use the command-line interface to generate the details of a new bucket and credentials. Run the following command:

   # noobaa obc create <obc-name> -n openshift-storage

   Replace <obc-name> with a unique OBC name, for example, myappobc.

   Additionally, you can use the --app-namespace option to specify the namespace where the OBC configuration map and secret will be created, for example, myapp-namespace.

   Example output:

   INFO[0001] ✅ Created: ObjectBucketClaim "test21obc"

   The MCG command-line-interface has created the necessary configuration and has informed OpenShift about the new OBC.

2. Run the following command to view the OBC:

   # oc get obc -n openshift-storage

   Example output:

   NAME        STORAGE-CLASS                 PHASE   AGE
   test21obc   openshift-storage.noobaa.io   Bound   38s

3. Run the following command to view the YAML file for the new OBC:

   # oc get obc test21obc -o yaml -n openshift-storage

   Example output:

   apiVersion: objectbucket.io/v1alpha1
   kind: ObjectBucketClaim
   metadata:
     creationTimestamp: "2019-10-24T13:30:07Z"
     finalizers:
     - objectbucket.io/finalizer
     generation: 2
     labels:
       app: noobaa
       bucket-provisioner: openshift-storage.noobaa.io-obc
       noobaa-domain: openshift-storage.noobaa.io
     name: test21obc
     namespace: openshift-storage
     resourceVersion: "40756"
     selfLink: /apis/objectbucket.io/v1alpha1/namespaces/openshift-storage/objectbucketclaims/test21obc
     uid: 64f04cba-f662-11e9-bc3c-0295250841af
   spec:
     ObjectBucketName: obc-openshift-storage-test21obc
     bucketName: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4
     generateBucketName: test21obc
     storageClassName: openshift-storage.noobaa.io
   status:
     phase: Bound

4. Inside of your openshift-storage namespace, you can find the configuration map and the secret to use this OBC. The CM and the secret have the same name as the OBC. Run the following command to view the secret:

   # oc get -n openshift-storage secret test21obc -o yaml

   Example output:

   Example output:
   apiVersion: v1
   data:
     AWS_ACCESS_KEY_ID: c0M0R2xVanF3ODR3bHBkVW94cmY=
     AWS_SECRET_ACCESS_KEY: Wi9kcFluSWxHRzlWaFlzNk1hc0xma2JXcjM1MVhqa051SlBleXpmOQ==
   kind: Secret
   metadata:
     creationTimestamp: "2019-10-24T13:30:07Z"
     finalizers:
     - objectbucket.io/finalizer
     labels:
       app: noobaa
       bucket-provisioner: openshift-storage.noobaa.io-obc
       noobaa-domain: openshift-storage.noobaa.io
     name: test21obc
     namespace: openshift-storage
     ownerReferences:
     - apiVersion: objectbucket.io/v1alpha1
       blockOwnerDeletion: true
       controller: true
       kind: ObjectBucketClaim
       name: test21obc
       uid: 64f04cba-f662-11e9-bc3c-0295250841af
     resourceVersion: "40751"
     selfLink: /api/v1/namespaces/openshift-storage/secrets/test21obc
     uid: 65117c1c-f662-11e9-9094-0a5305de57bb
   type: Opaque

   The secret gives you the S3 access credentials.

5. Run the following command to view the configuration map:

   # oc get -n openshift-storage cm test21obc -o yaml

   Example output:

   apiVersion: v1
   data:
     BUCKET_HOST: 10.0.171.35
     BUCKET_NAME: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4
     BUCKET_PORT: "31242"
     BUCKET_REGION: ""
     BUCKET_SUBREGION: ""
   kind: ConfigMap
   metadata:
     creationTimestamp: "2019-10-24T13:30:07Z"
     finalizers:
     - objectbucket.io/finalizer
     labels:
       app: noobaa
       bucket-provisioner: openshift-storage.noobaa.io-obc
       noobaa-domain: openshift-storage.noobaa.io
     name: test21obc
     namespace: openshift-storage
     ownerReferences:
     - apiVersion: objectbucket.io/v1alpha1
       blockOwnerDeletion: true
       controller: true
       kind: ObjectBucketClaim
       name: test21obc
       uid: 64f04cba-f662-11e9-bc3c-0295250841af
     resourceVersion: "40752"
     selfLink: /api/v1/namespaces/openshift-storage/configmaps/test21obc
     uid: 651c6501-f662-11e9-9094-0a5305de57bb

   The configuration map contains the S3 endpoint information for your application.

Procedure

1. Log into the OpenShift Web Console.

2. On the left navigation bar, click Storage → Object Bucket Claims → Create Object Bucket Claim.

   1. Enter a name for your object bucket claim and select the appropriate storage class based on your deployment, internal or external, from the dropdown menu:

      Internal mode

      

      The following storage classes, which were created after deployment, are available for use:

      • ocs-storagecluster-ceph-rgw uses the Ceph Object Gateway (RGW)
      • openshift-storage.noobaa.io uses the Multicloud Object Gateway (MCG)

      External mode

      

      The following storage classes, which were created after deployment, are available for use:

      • ocs-external-storagecluster-ceph-rgw uses the RGW

      • openshift-storage.noobaa.io uses the MCG

        Note

        The RGW OBC storage class is only available with fresh installations of OpenShift Data Foundation version 4.5. It does not apply to clusters upgraded from previous OpenShift Data Foundation releases.

   2. Click Create.

      Once you create the OBC, you are redirected to its detail page:

      

Procedure

1. On the left navigation bar, click Storage → Object Bucket Claims.

2. Click the Action menu (⋮) next to the OBC you created.

   1. From the drop-down menu, select Attach to Deployment.

      

   2. Select the desired deployment from the Deployment Name list, then click Attach.

      

Procedure

1. Log into the OpenShift Web Console.

2. On the left navigation bar, click Storage → Object Buckets.

   

   Alternatively, you can also navigate to the details page of a specific OBC and click the Resource link to view the object buckets for that OBC.

3. Select the object bucket you want to see details for. You are navigated to the Object Bucket Details page.

Procedure

1. On the left navigation bar, click Storage → Object Bucket Claims.

2. Click the Action menu (⋮) next to the Object Bucket Claim (OBC) you want to delete.

   
   1. Select Delete Object Bucket Claim.
   2. Click Delete.

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 the 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>

   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.

      You can also add storage resources by applying a YAML. First create a secret with 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>

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

      Replace <namespacestore-secret-name> with a unique name.

      Then apply the following YAML:

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

   4. Replace <namespacestore> with a unique name.
   5. Replace <namespacestore-secret-name> with the secret created in the previous step.
   6. Replace <namespace-secret> with the namespace used to create the secret in the previous step.
   7. Replace <target-bucket> with the AWS S3 bucket you created for the namespacestore.

2. Run the following command to create a bucket class:

   noobaa bucketclass create namespace-bucketclass cache <my-cache-bucket-class> --backingstores <backing-store> --hub-resource <namespacestore>

   1. Replace <my-cache-bucket-class> with a unique bucket class name.
   2. Replace <backing-store> with the relevant backing store. You can list one or more backingstores separated by commas in this field.
   3. Replace <namespacestore> with the namespacestore created in the previous step.

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

   noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>

   1. Replace <my-bucket-claim> with a unique name.
   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 the 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>

   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.

      You can also add storage resources by applying a YAML. First, 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>

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

      Replace <namespacestore-secret-name> with a unique name.

      Then apply the following YAML:

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

   4. Replace <namespacestore> with a unique name.
   5. Replace <IBM COS ENDPOINT> with the appropriate IBM COS endpoint.
   6. Replace <backingstore-secret-name> with the secret created in the previous step.
   7. Replace <namespace-secret> with the namespace used to create the secret in the previous step.
   8. Replace <target-bucket> with the AWS S3 bucket you created for the namespacestore.

2. Run the following command to create a bucket class:

   noobaa bucketclass create namespace-bucketclass cache <my-bucket-class> --backingstores <backing-store> --hubResource <namespacestore>

   1. Replace <my-bucket-class> with a unique bucket class name.
   2. Replace <backing-store> with the relevant backing store. You can list one or more backingstores separated by commas in this field.
   3. Replace <namespacestore> with the namespacestore created in the previous step.

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

   noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>

   1. Replace <my-bucket-claim> with a unique name.
   2. Replace <custom-bucket-class> with the name of the bucket class created in step 2.

Procedure

1. Log in to OpenShift Web Console.
2. From the MCG user interface, click Overview → Add Storage Resources.
3. In the window, click Deploy Kubernetes Pool.
4. In the Create Pool step create the target pool for the future installed nodes.
5. In the Configure step, configure the number of requested pods and the size of each PV. For each new pod, one PV is to be created.
6. In the Review step, you can find the details of the new pool and select the deployment method you wish to use: local or external deployment. If local deployment is selected, the Kubernetes nodes will deploy within the cluster. If external deployment is selected, you will be provided with a YAML file to run externally.
7. All nodes will be assigned to the pool you chose in the first step, and can be found under Resources → Storage resources → Resource name.