container-storage-interface
Volume capacity could not be verified for pre-provisioned volumes
For a pre-provisioned CSI volume (e.g. k8s statically provisioned PersistentVolume) the relevant API calls are ControllerPublishVolume, NodeStageVolume, NodePublishVolume. CreateVolume is not called since the volume is already provisioned. CreateVolume is the only mentioned method that contains capacity, so it's not possible to verify the actual capacity of the volume for a pre-provisioned volume.
While such a configuration calls for an admin to provide an adequate pre-provisioned volume configuration (i.e. correct capacity spec for a PersistentVolume), additional verification should be implemented by a driver so that the end-user doesn't experience unexpected capacity shortage
This sounds like an issue that should be filed against some k8s project, not the general CSI spec.
On Tue, May 28, 2019, 2:36 AM alexanderKhaustov [email protected] wrote:
For a pre-provisioned CSI volume (e.g. k8s statically provisioned PersistentVolume) the relevant API calls are ControllerPublishVolume, NodeStageVolume, NodePublishVolume. CreateVolume is not called since the volume is already provisioned. CreateVolume is the only mentioned method that contains capacity, so it's not possible to verify the actual capacity of the volume for a pre-provisioned volume.
While such a configuration calls for an admin to provide an adequate pre-provisioned volume configuration (i.e. correct capacity spec for a PersistentVolume), additional verification should be implemented by a driver so that the end-user doesn't experience unexpected capacity shortage
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/container-storage-interface/spec/issues/367?email_source=notifications&email_token=AAR5KLC6OEKZMQ4H7U5UZXTPXTHFPA5CNFSM4HQAFGOKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GWERDBA, or mute the thread https://github.com/notifications/unsubscribe-auth/AAR5KLGC6RZCBSRJ72PTP6DPXTHFPANCNFSM4HQAFGOA .
I've been unable to find an explicit statement in the spec whether static provisioning is in its scope or not. The possibility to skip the Controller implementation suggests that it is.
If it's in the scope then resolving the issue would require to expand the parameters passed to ControllerPublishVolume rpc, so an update to the spec would be necessary, would it not?
The possibility to skip the Controller implementation suggests that it is
Actually, figure 7 also suggests that it is