Multiple PVC on same pod with the same access point

[andre-lx]

/kind bug

What happened?

Hello.

I'm still facing thie issue #167 using the same access point in two different PV mounted to the same pod.

On azure, using their csi driver this does not happen, since the volume handle is always different. For example:

volumeHandle: xxxxxx#xxxx331#shared##pvc-xxxx#e7048599-f033-404a-9377-775c43621e97

Using the efs csi driver the volume handle is always the same, so this will lead to this error. As an example:

volumeHandle: fs-xxx::fsap-xxxx

How to reproduce it (as minimally and precisely as possible)?

apiVersion: v1
kind: PersistentVolume
metadata:
  name: volume1
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 1Ti
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-xxx::fsap-xxx
  persistentVolumeReclaimPolicy: Retain
  storageClassName: sc
  volumeMode: Filesystem
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: volume1-claim
spec:
  storageClassName: sc
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Ti
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: volume2
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 1Ti
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-xxx::fsap-xxx
  persistentVolumeReclaimPolicy: Retain
  storageClassName: sc
  volumeMode: Filesystem
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: volume2-claim
spec:
  storageClassName: sc
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Ti
---
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - image: nginx:latest
    name: nginx
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - mountPath: /mnt/xxx/
      name: volume1
      subPath: a/b
    - mountPath: /mnt/yyy/
      name: volume2
      subPath: c/d
  volumes:
  - name: volume1
    persistentVolumeClaim:
      claimName: volume1-claim
  - name: volume2
    persistentVolumeClaim:
      claimName: volume2-claim

What you expected to happen?

Should be possible to mount two pvc to the same pod that uses the same access point.

I'm not sure entirely if the volumeHandle is the issue, but looks like it is.
I'm also not sure if there is anything that could be done on the efs csi driver, since this is the right behaviour on the kubernetes side. But we are facing this issue, and we would like to know if there are any solution to mitigate this.

Thanks, André Vieira

Environment

• Kubernetes version (use kubectl version): 1.22
• Driver version: 1.4.7

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.