Closed gnufied closed 5 years ago
By extension, wouldn't it be required that NodeGetVolumeStats
also receive volume_capability
information, to distinguish between when to return block stats and when to return filesystem stats created on the block device, based on volume type?
I am asking to understand if this or a subsequent request should cover this requirement as well, thanks.
May be.. I am interested in learning how a plugin will use that information for NodeGetVolumeStats
call. In many cases for raw block devices - it is not possible to get used capacity etc. Lets open another issue to track that?
May be.. I am interested in learning how a plugin will use that information for
NodeGetVolumeStats
call. In many cases for raw block devices - it is not possible to get used capacity etc. Lets open another issue to track that?
For block volumes we may omit used
and available
as per the spec [1].
I do not have this problem yet, so I am not opening an issue on this, unless we want to invite further feedback.
I dropped the comment here as, if we are unable to auto detect a block volume without the volume_capability
information in NodeExpandVolumeRequest
RPC, the problem would persist for the NodeGetVolumeStats
RPC (and other such RPCs) as well. Hence should this issue expand the initial problem statement when considering a solution?
If we add volume_capability
in ControllerExpandVolume
this helps establish an explicit contract between CSI driver and CO. So that CSI driver can use node_expansion_required
filed to indicate CO to call NodeExpandVolume
or not.
Currently
ControllerExpandVolumeRequest
andNodeExpandVolumeRequest
do not contain volume capability information. This could be problematic because - a plugin may use this information to tweak resizing flow. Such as:false
fromControllerExpandVolume
call if for certain types of volumes (raw block) noNodeExpandVolume
call is necessary.cc @bswartz @msau42 @wongma7