-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Storage Classes - contradicting behavior statements #47297
Comments
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the The 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-sigs/prow repository. |
and one more place https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/#defaulting-behavior "Note that if you set the storageclass.kubernetes.io/is-default-class annotation to true on more than one StorageClass in your cluster, and you then create a PersistentVolumeClaim with no storageClassName set, Kubernetes uses the most recently created default StorageClass." |
/sig storage |
The test on local minikube cluster (v.1.30.0) showed that PVC provisioned (BOUND state) with the latest "default" StorageClass assigned. So, the description of DefaultStorageClass is misleading. |
Is this a duplicate of issue #42288? |
/language en |
@sftim yes, it is a duplicate. The documentation hasn't been updated for a year |
/close not-planned There is an existing issue; help is welcome. |
@sftim: Closing this issue, marking it as "Not Planned". In response to this:
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-sigs/prow repository. |
/assign |
/unassign |
The default Storage class behaviour in https://kubernetes.io/docs/concepts/storage/storage-classes/#default-storageclass says:
"If you set the storageclass.kubernetes.io/is-default-class annotation to true on more than one StorageClass in your cluster, and you then create a PersistentVolumeClaim with no storageClassName set, Kubernetes uses the most recently created default StorageClass."
whereas, in the addmission controllers page (https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) for controller that does this amendment:
"This admission controller does not do anything when no default storage class is configured. When more than one storage class is marked as default, it rejects any creation of PersistentVolumeClaim with an error and an administrator must revisit their StorageClass objects and mark only one as default. This admission controller ignores any PersistentVolumeClaim updates; it acts only on creation."
So, what is the correct one?
Thanks
The text was updated successfully, but these errors were encountered: