search

container-storage-interface / spec

Container Storage Interface (CSI) Specification.
Apache License 2.0
1.34k stars 373 forks source link

Volume capacity could not be verified for pre-provisioned volumes #367

Open alexanderKhaustov opened 5 years ago

alexanderKhaustov commented 5 years ago

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

jdef commented 5 years ago

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 notifications@github.com 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 .

alexanderKhaustov commented 5 years ago

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?

alexanderKhaustov commented 5 years ago

The possibility to skip the Controller implementation suggests that it is

Actually, figure 7 also suggests that it is