A request with AccessMode UNKNOWN should (presumably - the purpose of this mode is unstated) always be rejected by the SP and it should never send a response with that AccessMode.
Of the five others, Kubernetes uses only three (RWO, ROX, RWX) and "A volume can only be mounted using one access mode at a time, even if it supports many", so it seems that a CSI driver that supports Kubernetes only can assume the VolumeCapability passed to NodeStageVolume and NodePublishVolume will be the same as that passed to ControllerPublishVolume; also, that ControllerPublishVolume will be passed the same VolumeCapability if the volume is published to multiple nodes simultaneously.
In other words, the CSI driver can reject a Publish/Stage/Publish request with an AccessMode differing from one currently in effect for that volume.
So supporting Kubernetes seems fine here.
However, the CSI spec is unclear to me.
Suppose a MULTI_NODE_SINGLE_WRITER volume is published to multiple nodes. Should the CSI driver reject such requests unless readonly is set to true on all but one of those requests? My understanding is No, that it's the responsibility of the consumer to do any coordination to prevent simultaneous writes, i.e., the contract is that the contract is not "give me a connections and make sure only one of them can write" but "give me connections that allow one writer".
Suppose a volume supports MULTI_NODE_SINGLE_WRITER. In that case, it also supports MULTI_NODE_READER_ONLY, SINGLE_NODE_WRITER, and SINGLE_NODE_READER_ONLY.
What if it is published to one node as MULTI_NODE_READER_ONLY and there's a request to publish it to another as SINGLE_NODE_WRITER, should it succeed?
It depends on whether MULTI_NODE_READER_ONLY is interpreted as "I only need to read it from this node" or "I don't want the volume to be written while I'm reading it".
Similarly, can a CO request a different VolumeCapability in NodeStageVolume from that requested at ControllerPublishVolume, and can the capability in NodePublishVolume differ from that in NodeStageVolume?
The words "how the CO intends to use the volume" from ControllerPublishVolumeRequest onwards suggests that it should be the same, but if there's an explicit statement then I missed it.
So are more conservative uses allowed, e.g., can MULTI_NODE_SINGLE_WRITER at ControllerPublishVolume become SINGLE_NODE_WRITER at NodeStageVolume and SINGLE_NODE_READER_ONLY at NodePublishVolume?
Can it be permissible for a CSI driver to reject a request with an AccessMode differing from that used in any other Publish/Stage/Publish presently in operation for that volume, as it seems is appropriate where Kubernetes is the CO?
A request with AccessMode UNKNOWN should (presumably - the purpose of this mode is unstated) always be rejected by the SP and it should never send a response with that AccessMode. Of the five others, Kubernetes uses only three (RWO, ROX, RWX) and "A volume can only be mounted using one access mode at a time, even if it supports many", so it seems that a CSI driver that supports Kubernetes only can assume the VolumeCapability passed to NodeStageVolume and NodePublishVolume will be the same as that passed to ControllerPublishVolume; also, that ControllerPublishVolume will be passed the same VolumeCapability if the volume is published to multiple nodes simultaneously. In other words, the CSI driver can reject a Publish/Stage/Publish request with an AccessMode differing from one currently in effect for that volume. So supporting Kubernetes seems fine here.
However, the CSI spec is unclear to me.
Suppose a MULTI_NODE_SINGLE_WRITER volume is published to multiple nodes. Should the CSI driver reject such requests unless readonly is set to true on all but one of those requests? My understanding is No, that it's the responsibility of the consumer to do any coordination to prevent simultaneous writes, i.e., the contract is that the contract is not "give me a connections and make sure only one of them can write" but "give me connections that allow one writer".
Suppose a volume supports MULTI_NODE_SINGLE_WRITER. In that case, it also supports MULTI_NODE_READER_ONLY, SINGLE_NODE_WRITER, and SINGLE_NODE_READER_ONLY.
What if it is published to one node as MULTI_NODE_READER_ONLY and there's a request to publish it to another as SINGLE_NODE_WRITER, should it succeed? It depends on whether MULTI_NODE_READER_ONLY is interpreted as "I only need to read it from this node" or "I don't want the volume to be written while I'm reading it".
Similarly, can a CO request a different VolumeCapability in NodeStageVolume from that requested at ControllerPublishVolume, and can the capability in NodePublishVolume differ from that in NodeStageVolume? The words "how the CO intends to use the volume" from ControllerPublishVolumeRequest onwards suggests that it should be the same, but if there's an explicit statement then I missed it. So are more conservative uses allowed, e.g., can MULTI_NODE_SINGLE_WRITER at ControllerPublishVolume become SINGLE_NODE_WRITER at NodeStageVolume and SINGLE_NODE_READER_ONLY at NodePublishVolume?
Can it be permissible for a CSI driver to reject a request with an AccessMode differing from that used in any other Publish/Stage/Publish presently in operation for that volume, as it seems is appropriate where Kubernetes is the CO?