-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow more templating substitutions in subDir #771
Comments
I have a corporate requirement to mount share that has preexisting structure, roughly I see that there is a LOT of discussion in this area... And this goes from 2018 ... |
Could you elaborate a bit more on "Misuse of StorageClass can lead to wipe of whole share as well (via Recycle/Delete) "? |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
Is your feature request related to a problem?/Why is this needed
Currently in subDir there are some substitutions allowed: pvc.metadata.name, pv.metadata.name and namespace.
Because (in a namespace) pvc.metadata.name HAS to be unique AND has DNS name requirements, directory names created are forced to be unnecessary long and are very limited in characters that can be used.
For example, having:
That would create for example on nfs following:
/SHARE/test/deployment1-nfs-data
,/SHARE/test/deployment1-nfs-shared
where I would like to be able to create just:
/SHARE/test/data
,/SHARE/test/shared
Describe the solution you'd like in detail
I suppose easiest would be to allow use of annotation for templating, like
${pvc.metadata.annotations[annotation_name]}
or similar (similar as external-provisioner can reference secrets via pvc I guess?).Describe alternatives you've considered
I cannot name PVC shorter due to clashed between different deployments and different storage classes. Also using inline/ephemeral volumes is not possible as CSIDriver specifies that it supports only Persistent volumes.
I could share some PVC between deployments, but that depends on accessMode as well, but that shaves off
deployment1-
from name only.Another option is using PVC name like
nfs
and mounting usingsubPath
, but then PVC/PV deletion removes too much.One way I found is to use separate StorageClass for each pod with static subDir, but that is a bit of overkill/misuse I guess?
Unless I am trying to use this completely wrong and there is a better way that I did not consider?
The text was updated successfully, but these errors were encountered: