-
Notifications
You must be signed in to change notification settings - Fork 1.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
CSI inline volume size #1409
CSI inline volume size #1409
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: pohly 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 |
@pohly: GitHub didn't allow me to request PR reviews from the following users: satoru-takeuchi. Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs. 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/test-infra repository. |
b4e3be6
to
4bd8edc
Compare
It was moved to kubernetes#1409.
mount](https://kubernetes-csi.github.io/docs/pod-info.html) feature: | ||
if (and only if) the driver enables that, then a new | ||
`csi.storage.k8s.io/size` entry in | ||
`NodePublishVolumeRequest.publish_context` is set to the string |
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's not publish_context, but volume_context. For more information, please refer to the following PR.
As a side note, I found this documentation error when reviewing this KEP, thanks!
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.
Good catch and thanks for taking care of it also in the docs from which I copied this. I wonder how many other developers have skipped over this without noticing the mistake...
Fixed.
string. | ||
|
||
This has to be optional because CSI drivers written for 1.16 might do | ||
strict validation of the `publish_context` content and reject volumes |
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.
Same as above.
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.
Fixed.
I left some comments, others are LGTM. |
This was found by Satoru Takeuchi and also fixed by him in kubernetes-csi/docs#249.
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.
LGTM
ea36596
to
a75f17c
Compare
I added a75f17c since @satoru-takeuchi reviewed this PR, with only one minor change to the proposal: the size string passed to the CSI driver is now explicitly documented as value in plain decimal to simplify parsing. The main change is the addition of the parts that are needed for "implementable". /assign @saad-ali For final review and approval. |
This adds the missing details (test plan, implementation history). Also clarifies what exactly the string representation of the size is when passed to the CSI driver.
a75f17c
to
1a557c6
Compare
vendor-specific parameter, it's not available to the Kubernetes | ||
scheduler. | ||
|
||
### fsSize field |
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.
Dose the scheduler have to look at this field and compare it with the storage pool capacity reported in #1353?
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.
Yes, that was the original motivation for adding this field.
/hold With #1353 on hold there is no urgent need to get this merged. More importantly, I'm starting to suspect that adding more features to CSI inline ephemeral volumes is just going to make the code base too complicated. To me it seems more promising to map inline volumes to the normal provisioning and then let the normal code paths deal with provisioning, failure recovery, etc. One additional bonus would be that CSI drivers do not need to be modified to work with ephemeral inline volumes. Here's a rough outline of that idea (from https://kubernetes.slack.com/archives/C8EJ01Z46/p1580043788038400?thread_ts=1579890578.025900&cid=C8EJ01Z46):
One concern about this approach is that these generated PVCs will be visible to users and users might do "bad things" (TM) with them because they typically have permission to do so. But the same is true for pods created by a stateful set. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
I think this KEP can be closed now that we are going with this new one: #1701. |
The proposal is to introduce a standardized parameter for the size of ephemeral inline volumes. This will help users (consistent API for different drivers) and enable the implementation of new functionality in Kubernetes (capacity-aware pod scheduling).
Original this was part of the Storage Capacity Constraints for Pod Scheduling KEP, but as it also makes sense by itself it was split out.
Enhancement issue: #1472