access modes not applied to imported volumes

[erhank]

Describe the bug
Imported a vol/group with ReadWriteMany access modes on the PVC and volume isn't writable by pod containers (Kubeflow Jupyter Notebook)

Environment
Provide accurate information about the environment to help us reproduce the issue.

• Trident version: 20.01.1
• Trident installation flags used: -d -n trident
• Container runtime: Docker CE 19.03.8
• Kubernetes version: 1.15.3
• Kubernetes orchestrator: Stock K8s
• Kubernetes enabled feature gates: none...standard 1.15 feature set
• OS: RHEL 7.7
• NetApp backend types: AFF A800 9.6P5
• Other:

To Reproduce
Import a flexgroup with access mode RWX aka ReadWriteMany
Reference it in a pod

Expected behavior
The volume mounted in the pod should be writable

Additional context

[erhank]

Edited this issue after troubleshooting with NTAP support....the original failure to enforce ROX was an artifact of our having mounted the volume directly and changing filesystem modes for another purpose. Our original assumption is that R/O vs. R/W was enforced via mount options, but it's clearly via modes on the PV filesystem.

We now understand that the issue is broader in regards to Trident imported volumes in general. We tested with a newly-provisioned FlexGroup in the opposite direction:

• Create in ONTAP
• Import into Trident w/ access mode ReadWriteMany
• Attach the PVC to a Pod
• Validate that create/write/update is denied

[erhank]

Sample of PVC use to test the above assertion -- despite ReadWriteMany being set, imported FlexGroup is not writable in Pod

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
 name: ntaptestgroup2
 namespace: ntaptest
spec:
 accessModes:
   - ReadWriteMany
 storageClassName: ontap-ai-flexgroups-retain

[wonderland]

Beyond the access mode, the file system permissions are relevant as well. What user (in the pod) tries to write? What permissions are set on the file system? Maybe (temporarily) set it to 777 from an external system, then try again, just to see if this causes the issue or not..

[nareshkumargunjalli]

Hello @erhank ,

We had reproduced this issue internally and after our internal tests and analysis we have following action items..

• Trident will be fixed to set the unix-permissions to 777 for the imported volumes if unix-permissions are not explicitly set in the backend definition.
  If the backend definition is configured with unix-permissions, respective unix-permissions will be applied on the imported volumes.
  Until this fix is available, it is suggested to set the unix-permissions to 777 on the ONTAP volume before it is imported into Trident.

• We would also like to suggest an alternative Action Plan in which you need not create multiple SCs for a single backend to overcome the issue with ROX accessMode.
  Create two backend's for the same SVM to imply the accessModes via different values for "nfsMountOptions" config.
  You can set nfsMountOptions to "ro" in one backend definition and "rw" for another backend definition.
  When backends are created this way, you apply the accessModes specified in the PVC config by choosing the right storage class(mapping to a corresponding ro/rw backend).

Thanks,
Naresh

[gnarl]

Fixed with commit 0f367d5.

[gnarl]

This issue is fixed in the Trident 20.07 release.