[manila-csi-plugin] If Manila CSI plugin supports Access Mode ReadWriteOnce

[syy6]

Hi,
In our envrioment, we create Manila PV with Access Mode ReadWriteOnce as below

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: nfs.manila.csi.openstack.org
    volume.kubernetes.io/provisioner-deletion-secret-name: manila-csi-plugin
    volume.kubernetes.io/provisioner-deletion-secret-namespace: kube-system
  finalizers:
  - kubernetes.io/pv-protection
  name: XXXXX
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 20Gi

and we don't get any error message. But per our test, it seems the ReadWriteOnce doesn't reallt take effect, when a Pod A on Node M still are in Terminating status, another Pod B on Node N already can mount it and running.

We checked the code, VolumeCapability_AccessMode_SINGLE_NODE_WRITER(ReadWriteOnce) is mentioned, but it seems there is no real logic to control it in the manila-csi-plugin driver.

We also notice a document from OpenShift, actually OpenStack Manila only supports ReadWriteOncePod & ReadWriteMany.

Could U please help to check if Manila CSI plugin supports Access Mode ReadWriteOnce? If not, if there is any other way we can achieve the same function here? Thanks!

[jichenjc]

there are some issues opened before for this but I am guessing it's not supported ReadWriteOnce
I am not sure whether openshift downstream made improvement directly instead of upstream..

@gman0 @zetaab correct me if I am wrong

[zetaab]

we are not using manila, so difficult to answer this issue. But in general manila is readwritemany

[gman0]

Hello @syy6, indeed the driver never supported this, and the mode validation is very relaxed because of historical reasons.

We've never really seen too convincing use cases to get this implemented, but in any case it shouldn't be too hard if you only need attachment tracking within the cluster. See https://github.com/kubernetes-csi/external-attacher

Note that the Manila service itself does not support attachments at the moment, and there would be nothing stopping other clients from accessing the share.

[syy6]

Thanks @jichenjc @zetaab @gman0, we have a tricky issue here.
We are using ReplicaSet (with replica = 1) for our service, and we have podAntiAffinity for the ReplicaSet, combined with accessModes ReadWriteOnce, we hope to use it to prevent simultaneous access to PVC.
But we see the multiple "mount" to manila share can happen when an old version of the Pod of the ReplicaSet is still in Terminating status, but new version of the Pod already starts. In this case, the old & new Pod would write to same file in same time and the file might be corrupted.

[kayrus]

What I'm curious is whether we need to implement changes listed here?