-
Notifications
You must be signed in to change notification settings - Fork 1.6k
KEP-5489: Enable defining a default StorageClass for each specific volume access mode #5492
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
base: master
Are you sure you want to change the base?
Conversation
savirg
commented
Aug 22, 2025
- One-line PR description: Enable defining a default StorageClass for each specific volume access mode
- Issue link: Enable defining a default StorageClass for each specific volume access mode #5489
- Other comments:
Welcome @savirg! |
Hi @savirg. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
427bfa3
to
d326612
Compare
/ok-to-test |
/assign |
- Feature implemented behind a feature flag | ||
- Initial e2e tests completed and enabled | ||
|
||
#### Beta |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have the beta and GA sections been filled out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do I need to fill them now or after the alpha release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to fill it out now. If it needs further adjustments in later releases, we can still change them.
--> | ||
|
||
- [ ] Feature gate (also fill in values in `kep.yaml`) | ||
- Feature gate name: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fill these out
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
not need to be as detailed as the proposal, but should include enough | ||
information to express the idea and why it was not acceptable. | ||
--> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I would mention the other alternatives discussed in this issue: kubernetes/kubernetes#89911
The main challenges with the webhook or mutating admission policy approaches is the ordering with the builtin defaultstorageclass admission controller. We would have to migrate the existing admission controller to solve the ordering problems, and that still wouldn't address the logic in the PV controller.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
keps/sig-storage/5489-default-storage-class-per-access-mode/kep.yaml
Outdated
Show resolved
Hide resolved
keps/sig-storage/5489-default-storage-class-per-access-mode/kep.yaml
Outdated
Show resolved
Hide resolved
d326612
to
938eecc
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: savirg The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
||
# The milestone at which this feature was, or is targeted to be, at each stage. | ||
milestone: | ||
alpha: "v1.35" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be beta? Or we still go through 3 release cycles?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alpha, beta, GA is the typical cycle
/retest |
@savirg: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
If e2e tests are not necessary or useful, explain why. | ||
--> | ||
|
||
For the **Alpha** release, a focused suite of end-to-end (e2e) tests will be added to `test/e2e/storage`. These tests are designed to validate the complete user journey, from `PersistentVolumeClaim` (PVC) creation to successful `PersistentVolume` (PV) provisioning and binding, ensuring the feature works correctly in a fully functional cluster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The challenge with e2e tests is different environments won't have the supported storage providers to test the full provisioning path. And changing the default storageclasses may not be allowed in some environments. I think for e2e tests, we need to leave it to the cluster provider to install appropriate storageclasses, and in the tests, if the default storageclasses are set, then we trigger the tests.
- Feature implemented behind a feature flag | ||
- Initial e2e tests completed and enabled | ||
|
||
#### Beta |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to fill it out now. If it needs further adjustments in later releases, we can still change them.
|
||
#### Kubernetes Mutating Admission Policies (CEL) | ||
|
||
This approach would leverage the built-in `MutatingAdmissionPolicy` feature, which uses the Common Expression Language (CEL) to define policies that can modify objects during admission. An administrator would create a `MutatingAdmissionPolicy` resource that inspects the `accessModes` of an incoming PVC and mutates the `storageClassName` field if it is empty. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This approach is actually a bit more complex. In order to choose which storageClassName to set, we typically have to iterate over all StorageClasses to find the ones with the right annotations and also consider all the priority rules that you outlined earlier. CEL cannot do this kind of logic, so we would need to implement a controller that evaluates the PVC and the StorageClasses, and then associate a ConfigMap to the PVC with the final result.