spec: Move AccessMode to VolumeCapability
#82
Conversation
This patch fixed some style issues in the spec according to the contribution guide.
This patch moved `AccessMode` to `VolumeCapability`, because access mode is strongly related to the filesystem type. For instance, a plugin might support `SINGLE_NODE_WRITER` for `xfs`, and `MULTI_NODE_READER_ONLY` for `gfs2`. This patch also removed `VolumeCapability` fields from `ControllerGetCapabilities` and `NodeGetCapabilities` RPCs. It becomes very tedious to ask the plugins to enumerate all volume capabilities that a plugin supports, and probably provides less value. To check the capablities of a volume, the CO should use `ValidateVolumeCapabilities`. This applies to both newly provisioned volumes and pre-existing volumes. See discussion in container-storage-interface#61.
|
cc @jsafrane |
|
Thanks for this, posting this list of impacted RPCs for sanity checks:
|
| @@ -498,10 +531,6 @@ message VolumeInfo { | |||
| // NFS share). If set, it MUST be non-zero. | |||
| uint64 capacity_bytes = 1; | |||
|
|
|||
There was a problem hiding this comment.
Access mode should still be in the returned VolumeInfo no? That way SP can satisfy with access_mode equal to or better than what was asked for?
There was a problem hiding this comment.
If access mode is part of VolumeCapability as well as VolumeInfo then ValidateVolumeCapabilities seems confusing because it has both data types, and each would have an AccessMode.
If access mode is NOT part of VolumeInfo what prevents the SP from satisfying the request with a mode equal to or better than what was requested? If the SP upgrades the access mode in a CreateVolume request, does the CO really care as long as it gets the minimum behavior it needs for the workload it wants to run?
There was a problem hiding this comment.
I guess the use case I am trying to understand is this:
CreateVolume(VolumeCapability...)whereVolumeCapabilitycontainsaccess_modeset toSINGLE_NODE_READER_ONLY.- The volume plugin satisfies the request by provisioning a volume that is
MULTI_NODE_READER_ONLY. - The
CreateVolumeResponsedoes not contain the actualaccess_mode, because it was removed fromVolumeInfo.
How would the CO figure out the actual access_mode of the newly created volume? By issuing a follow up ValidateVolumeCapabilities call?
There was a problem hiding this comment.
Given the above workflow, why does the CO care that the provisioned volume is actually MULTI_NODE_READER_ONLY vs. what was requested? Is it trying to make decisions about other workloads on other nodes that may be trying to use the same volume (and if so, shouldn't it stop them from doing so because step 1 requested SINGLE_NODE_READER_ONLY to begin with..)?
There was a problem hiding this comment.
@saad-ali, thanks for the feedback. As @jdef pointed out, if the CO requested certain AccessMode in the request, it probably shouldn't care about what is the actual capability of the volume (which might have a larger set of capabilities). For instance, to map to k8s concepts. If a user specified a PVC with access mode SINGLE_NODE_READER_ONLY, the PV dynamically provisioned for this PVC should probably have access mode SINGLE_NODE_READER_ONLY because that's what the user expects the volume to have. Whether the PV actually has MULTI_NODE_READER_ONLY capability or not doesn't matter to the user.
Also, I think @jsafrane made an excellent point in #61 that access_mode is usually tied to filesystem type. access_mode might be different depending on the underlying filesystem. So, returning just access_mode probably does not make sense.
I'd be OK that CreateVolumeResponse also returns a set of VolumeCapabilities that a volume actually has. But as @jsafrane pointed in #61, there might be a lot of combinations. That's the reason I remove those in the spec and always ask the CO to initiate the check using ValidateVolumeCapabilities based on what capabilities the user actually want the volume to have.
There was a problem hiding this comment.
Thanks for the clarification guys. I can't think of a good reason the CO might care other than for binding, which doesn't matter in the dynamic provisioning case. So further objection.
|
/lgtm |
This patch moved
AccessModetoVolumeCapability, because access modeis strongly related to the filesystem type. For instance, a plugin might
support
SINGLE_NODE_WRITERforxfs, andMULTI_NODE_READER_ONLYforgfs2.This patch also removed
VolumeCapabilityfields fromControllerGetCapabilitiesandNodeGetCapabilitiesRPCs. It becomesvery tedious to ask the plugins to enumerate all volume capabilities
that a plugin supports, and probably provides less value. To check the
capablities of a volume, the CO should use
ValidateVolumeCapabilities.This applies to both newly provisioned volumes and pre-existing volumes.
See discussion in #61.