The CSI Manila driver is able to create and mount OpenStack Manila shares. Snapshots and recovering shares from snapshots is supported as well (support for CephFS snapshots will be added soon).
| Option | Default value | Description |
|---|---|---|
--endpoint |
unix:///tmp/csi.sock |
CSI Manila's CSI endpoint |
--drivername |
manila.csi.openstack.org |
Name of this driver |
--nodeid |
none | ID of this node |
--share-protocol-selector |
none | Specifies which Manila share protocol to use for this instance of the driver. See supported protocols for valid values. |
--fwdendpoint |
none | CSI Node Plugin endpoint to which all Node Service RPCs are forwarded. Must be able to handle the file-system specified in share-protocol-selector. Check out the Deployment section to see why this is necessary. |
| Parameter | Required | Description |
|---|---|---|
type |
yes | Manila share type |
shareNetworkID |
no | Manila share network ID |
cephfs-mounter |
no | Relevant for CephFS Manila shares. Specifies which mounting method to use with the CSI CephFS driver. Available options are kernel and fuse, defaults to fuse. See CSI CephFS docs for further information. |
nfs-shareClient |
no | Relevant for NFS Manila shares. Specifies what address has access to the NFS share. Defaults to 0.0.0.0/0, i.e. anyone. |
| Parameter | Required | Description |
|---|---|---|
shareID |
if shareName is not given |
The UUID of the share |
shareName |
if shareID is not given |
The name of the share |
shareAccessID |
yes | The UUID of the access rule for the share |
cephfs-mounter |
no | Relevant for CephFS Manila shares. Specifies which mounting method to use with the CSI CephFS driver. Available options are kernel and fuse, defaults to fuse. See CSI CephFS docs for further information. |
Note that the Node Plugin of CSI Manila doesn't care about the origin of a share. As long as the share protocol is supported, CSI Manila is able to consume dynamically provisioned as well as pre-provisioned shares (e.g. shares created manually).
Authentication with OpenStack may be done using either user or trustee credentials.
Mandatory secrets: os-authURL, os-region.
Mandatory secrets for user authentication: os-password, os-userID or os-userName, os-domainID or os-domainName, os-projectID or os-projectName.
Optional secrets for user authentication: os-projectDomainID or os-projectDomainName, os-userDomainID or os-userDomainName
Mandatory secrets for application credential authentication: os-applicationCredentialID or os-applicationCredentialName (when os-userID or os-userName and os-domainName are set), os-applicationCredentialSecret.
Mandatory secrets for trustee authentication: os-trustID, os-trusteeID, os-trusteePassword.
Optionally, a custom certificate may be sourced via os-certAuthorityPath (path to a PEM file inside the plugin container). By default, the usual TLS verification is performed. To override this behavior and accept insecure certificates, set os-TLSInsecure to true (defaults to false).
The CSI Manila driver deals with the Manila service only. All node-related operations (attachments, mounts) are performed by a dedicated CSI Node Plugin, to which all Node Service RPCs are forwarded. This means that the operator is expected to already have a working deployment of that dedicated CSI Node Plugin.
A single instance of the driver may serve only a single Manila share protocol. To serve multiple share protocols, multiple deployments of the driver need to be made. In order to avoid deployment collisions, each instance of the driver should be named differently, e.g. csi-manila-cephfs, csi-manila-nfs.
Snapshots require VolumeSnapshotDataSource=true feature gate.
The deployment consists of two main components: Controller and Node plugins along with their respective RBACs. Controller plugin is deployed as a StatefulSet and runs CSI Manila, external-provisioner and external-snapshotter. Node plugin is deployed as a DaemonSet and runs CSI Manila and csi-node-driver-registrar.
Deploying with Helm
This is the preferred way of deployment because it greatly simplifies the difficulties with managing multiple share protocols.
CSI Manila Helm chart is located in examples/manila-csi-plugin/helm-deployment.
First, modify values.yaml to suite your environment, and then simply install the Helm chart with $ helm install helm-deployment.
Note that the release name generated by helm install may not be suitable due to their length. The chart generates object names with the release name included in them, which may cause the names to exceed 63 characters and result in chart installation failure. You may use --name flag to set the release name manually. See helm installation docs for more info. Alternatively, you may also use nameOverride or fullnameOverride variables in values.yaml to override the respective names.
Manual deployment
All Kubernetes YAML manifests are located in manifests/manila-csi-plugin.
First, deploy the RBACs:
kubectl create -f csi-controllerplugin-rbac.yaml
kubectl create -f csi-nodeplugin-rbac.yaml
Deploy the CSIDriver CRD:
kubectl create -f csidriver.yaml
Before continuing, csi-controllerplugin.yaml and csi-nodeplugin.yaml manifests need to be modified: fwd-plugin-dir needs to point to the correct path containing the .sock file of the other CSI driver.
Next, MANILA_SHARE_PROTO and FWD_CSI_ENDPOINT environment variables must be set. Consult --share-protocol-selector and --fwdendpoint command line flags for valid values.
Finally, deploy Controller and Node plugins:
kubectl create -f csi-controllerplugin.yaml
kubectl create -f csi-nodeplugin.yaml
Successful deployment should look similar to this:
$ kubectl get all
NAME READY STATUS RESTARTS AGE
pod/openstack-manila-csi-controllerplugin-0 3/3 Running 0 2m8s
pod/openstack-manila-csi-nodeplugin-ln2xk 2/2 Running 0 2m2s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/openstack-manila-csi-controllerplugin ClusterIP 10.102.188.171 <none> 12345/TCP 2m8s
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
daemonset.apps/openstack-manila-csi-nodeplugin 1 1 1 1 1 <none> 2m2s
NAME READY AGE
statefulset.apps/openstack-manila-csi-controllerplugin 1/1 2m8s
...
To test the deployment further, see examples/csi-manila-plugin.
The table below shows Manila share protocols currently supported by CSI Manila and their corresponding CSI Node Plugins which must be deployed alongside CSI Manila.
| Manila share protocol | CSI Node Plugin |
|---|---|
CEPHFS |
CSI CephFS : v1.0.0 |
NFS |
CSI NFS : v1.0.0 |
If you'd like to contribute to CSI Manila, check out docs/developers-csi-manila.md to get you started.