Skip to main content

OpenStack Manila CSI Driver Operator

You can provision and manage OpenStack Manila storage in OpenShift Container Platform using the OpenStack Manila Container Storage Interface (CSI) Driver Operator and driver, which provide dynamic volume provisioning.

Overview of Manila CSI Driver Operator​

OpenShift Container Platform is capable of provisioning persistent volumes (PVs) using the Container Storage Interface (CSI) driver for the OpenStack Manila shared file system service.

Familiarity with persistent storage] and configuring CSI volumes is recommended when working with CSI Operator and driver. For more information, see "Understanding persistent storage" and "Configuring CSI volumes".

To create CSI-provisioned PVs that mount to Manila storage assets, OpenShift Container Platform installs the Manila CSI Driver Operator and the Manila CSI driver by default on any OpenStack cluster that has the Manila service enabled.

Manila CSI Driver Operator
The Manila CSI Driver Operator creates the required storage class that is needed to create persistent volumes claims (PVCs) for all available Manila share types. The Operator is installed in the openshift-cluster-csi-drivers namespace.
Manila CSI driver
The Manila CSI driver enables you to create and mount Manila PVs. The driver is installed in the openshift-manila-csi-driver namespace.

Additional resources

About CSI​

The Container Storage Interface (CSI) enables storage vendors to deliver plugins through a standard interface without modifying Kubernetes core code, replacing traditional embedded storage drivers.

CSI Operators give OpenShift Container Platform users storage options, such as volume snapshots, that are not possible with in-tree volume plugins.

Manila CSI Driver Operator limitations​

Before deploying the Manila CSI Driver Operator, understand the protocol, snapshot, and FSGroup limitations to ensure compatibility with your OpenStack storage configuration.

The following limitations apply to the Manila Container Storage Interface (CSI) Driver Operator:

Only NFS is supported
OpenStack Manila supports many network-attached storage protocols, such as NFS, CIFS, and CEPHFS, and these can be selectively enabled in the OpenStack cloud. The Manila CSI Driver Operator in OpenShift Container Platform only supports using the NFS protocol. If NFS is not available and enabled in the underlying OpenStack cloud, you cannot use the Manila CSI Driver Operator to provision storage for OpenShift Container Platform.
Snapshots are not supported if the back end is CephFS-NFS
To take snapshots of persistent volumes (PVs) and revert volumes to snapshots, you must ensure that the Manila share type that you are using supports these features. A Red Hat OpenStack administrator must enable support for snapshots (share type extra-spec snapshot_support) and for creating shares from snapshots (share type extra-spec create_share_from_snapshot_support) in the share type associated with the storage class you intend to use.
FSGroups are not supported
Since Manila CSI provides shared file systems for access by multiple readers and multiple writers, it does not support the use of FSGroups. This is true even for persistent volumes created with the ReadWriteOnce access mode. It is therefore important not to specify the fsType attribute in any storage class that you manually create for use with Manila CSI Driver.
warning

In Red Hat OpenStack Platform 16.x and 17.x, the Shared File Systems service (Manila) with CephFS through NFS fully supports serving shares to OpenShift Container Platform through the Manila CSI. However, this solution is not intended for massive scale. Be sure to review important recommendations in "CephFS NFS Manila-CSI Workload Recommendations for Red Hat OpenStack Platform".

Additional resources

Manila CSI volumes dynamic provisioning​

OpenShift Container Platform installs a storage class for each available Manila share type. To dynamically provision shared storage volumes that support concurrent access from multiple pods, you must create persistent volume claims (PVCs) by using Manila Container Storage Interface CSI storage classes.

The YAML files that are created are completely decoupled from Manila and from its Container Storage Interface (CSI) plugin. As an application developer, you can dynamically provision ReadWriteMany (RWX) storage and deploy pods with applications that safely consume the storage using YAML manifests.

You can use the same pod and persistent volume claim (PVC) definitions on-premise that you use with OpenShift Container Platform on AWS, Google Cloud, Azure, and other platforms, with the exception of the storage class reference in the PVC definition.

warning

By default, the access rule that is assigned to a volume is 0.0.0.0/0, which allows access from all IPv4 clients. To limit client access, create custom storage classes that use specific client IP addresses or subnets. For more information, see "Customizing Manila share access rules".

note

Manila service is optional. If the service is not enabled in Red Hat OpenStack Platform (RHOSP), the Manila CSI driver is not installed and the storage classes for Manila are not created.

Dynamically provisioning Manila CSI volumes by using the web console​

To dynamically provision shared storage volumes using the OpenShift Container Platform web console, create a persistent volume claim (PVC) by selecting a Manila CSI storage class.

Prerequisites

  • RHOSP is deployed with appropriate Manila share infrastructure so that it can be used to dynamically provision and mount volumes in OpenShift Container Platform.

Procedure

  1. In the OpenShift Container Platform web console, click Storage → Persistent Volume Claims.
  2. In the persistent volume claims overview, click Create Persistent Volume Claim.
  3. Define the required options on the resulting page.

    1. Select the appropriate storage class.

    2. Enter a unique name for the storage claim.

    3. Select the access mode to specify read and write access for the PVC you are creating.

      warning

      Use RWX if you want the PV that fulfills this PVC to be mounted to multiple pods on multiple nodes in the cluster.

  4. Define the size of the storage claim.
  5. Click Create to create the PVC and generate a PV.

Results

You can now use the new PVC to configure a pod.

Dynamically provisioning Manila CSI volumes by by using the CLI​

To dynamically provision shared storage volumes using the CLI, create and apply a persistent volume claim (PVC) YAML file that references a Manila CSI storage class.

Prerequisites

  • RHOSP is deployed with appropriate Manila share infrastructure so that it can be used to dynamically provision and mount volumes in OpenShift Container Platform.

Procedure

  1. Create and save a file with the PersistentVolumeClaim object described by the following YAML:

    pvc-manila.yaml
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: pvc-manila
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 10Gi
      storageClassName: csi-manila-gold
    • spec.accessModes: Use RWX if you want the PV that fulfills this PVC to be mounted to multiple pods on multiple nodes in the cluster.
    • spec.storageClassName: Specifies the name of the storage class that provisions the storage back end. Manila storage classes are provisioned by the Operator and have the csi-manila- prefix.

  2. Create the object you saved in the previous step by running the following command:

    $ oc create -f pvc-manila.yaml

    A new PVC is created.

  3. To verify that the volume was created and is ready, run the following command:

    $ oc get pvc pvc-manila

    The pvc-manila shows that it is Bound.

Results

You can now use the new PVC to configure a pod.

Customizing Manila share access rules​

To improve storage security by controlling which clients can mount volumes, create custom Manila storage classes that limit access to specific IP addresses or subnets.

By default, OpenShift Container Platform creates Manila storage classes that provide access to all IPv4 clients. To limit client access, you can define custom storage classes that use specific client IP addresses or subnets by using the nfs-ShareClient parameter.

warning

When using custom storage classes with restricted access rules, ensure that:

  • The specified IP addresses or subnets include all OpenShift Container Platform nodes that need to access the storage.
  • The Manila service in RHOSP supports the share type specified in the storage class.
  • Network connectivity exists between the allowed clients and the Manila share servers.

Prerequisites

  • Red Hat OpenStack Platform (RHOSP) is deployed with appropriate Manila share infrastructure.
  • Access to a cluster with administrator privileges.

Procedure

  1. Create a YAML file for your custom storage class based on the following example:

    Example custom storage class file
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: csi-manila-gold-restricted
    provisioner: manila.csi.openstack.org
    parameters:
      type: gold
      nfs-ShareClient: "10.0.0.0/24,192.168.1.100"
      csi.storage.k8s.io/provisioner-secret-name: manila-csi-secret
      csi.storage.k8s.io/provisioner-secret-namespace: openshift-manila-csi-driver
      csi.storage.k8s.io/controller-expand-secret-name: manila-csi-secret
      csi.storage.k8s.io/controller-expand-secret-namespace: openshift-manila-csi-driver
      csi.storage.k8s.io/node-stage-secret-name: manila-csi-secret
      csi.storage.k8s.io/node-stage-secret-namespace: openshift-manila-csi-driver
      csi.storage.k8s.io/node-publish-secret-name: manila-csi-secret
      csi.storage.k8s.io/node-publish-secret-namespace: openshift-manila-csi-driver
    allowVolumeExpansion: true
    • metadata.name: Specifies a descriptive name for your custom storage class.
    • parameters.type: Specifies the Manila share type. This type must match an existing share type in your RHOSP environment.
    • parameters.nfs.ShareClient: Comma-separated list of IP addresses or CIDR subnets allowed to access the NFS shares. The nfs-ShareClient parameter accepts various formats:

      • Single IP address: 192.168.1.100

      • CIDR subnet: 10.0.0.0/24

      • Multiple entries: 10.0.0.0/24,192.168.1.100,172.16.0.0/16 Ensure that the specified IP addresses or subnets include the OpenShift Container Platform cluster nodes to allow proper mounting of the persistent volumes.

        In this example, access is restricted to the 10.0.0.0/24 subnet, and the specific IP address is 192.168.1.100.

  2. Apply the storage class from the file by running the following command:

    $ oc apply -f custom-manila-storageclass.yaml

  3. Verify that the storage class was created by running the following command:

    $ oc get storageclass csi-manila-gold-restricted
    Example output
    NAME                 		    PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
    csi-manila-gold-restricted	manila.csi.openstack.org   Delete          Immediate           true                   43m

  4. Create a persistent volume claim (PVC) that uses the custom storage class based on the following example:

    Example PVC file
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: pvc-manila-restricted
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 10Gi
      storageClassName: csi-manila-gold-restricted

    spec.storageClassName is the name of your custom storage class that has restricted access. In this example, the name is csi-manila-gold-restricted.

  5. Apply the PVC from the file by running the following command:

    $ oc apply -f pvc-manila-restricted.yaml