Allow setting the /spec/accessModes of a PVC created for the CSI snapshot data movement

[Borrelhapje]

Describe the problem/challenge you have

I'm using rook-ceph as a storage backend. It can take snapshots in O(1) time, but creating a new PVC from this snapshot takes much longer IF the PVC needs has write capabilities (as then rook-ceph goes and copies the complete data to a new PV). I just tried creating a new PVC from a volumesnapshot with /spec/accessModes set to ReadOnlyMany, and that is instant as rook-ceph just serves the snapshot. However, there seems to be no option to set the PVC accessModes in the Backup CRD.

Describe the solution you'd like

I'd like to be able to specify which accessModes the volumes created by the csi data movement plugin have (similarly to #7700 which would like to set the storageclass for performance reasons). If I understand the csi data movement plugin setup it should not need write access to a PVC being sent to s3.

Anything else you would like to add:

One could set ReadOnlyMany as the default value, however not all CSI providers may support it so I think it's fine to default to the accessModes of the original volume.

Environment:

• Velero version (use velero version): 1.13.0 (velero-plugin-for-csi 0.7.1, velero-plugin-for-aws 1.9.2)
• Kubernetes version (use kubectl version): 1.30
• Kubernetes installer & version: kubeadm
• Cloud provider or hardware configuration: debian bookworm
• OS (e.g. from /etc/os-release):

Vote on this issue!

This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

• 👍 for "The project would be better with this feature added"
• 👎 for "This feature will not enhance the project in a meaningful way"

[Lyndon-Li]

The PVC created from the snapshot is indeed used in readOnly way, let me check if we can add something like this --- use ReadOnlyMany first, if it fails, fallback to ReadWriteOnce