Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
CSI inline volume size #1409
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
[APPROVALNOTIFIER] This PR is NOT APPROVED
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.
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".
For final review and approval.
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.