search

container-storage-interface / spec

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

NodePublishVolume should not require multi-node capability if called on the same node with different target_paths #349

Open rgcostea opened 5 years ago

rgcostea commented 5 years ago

Per the spec, the NodePublishVolume RPC

MAY be called by the CO multiple times on the same node for the same volume with possibly different target_path and/or other arguments if the volume has MULTI_NODE capability (i.e., access_mode is either MULTI_NODE_READER_ONLY, MULTI_NODE_SINGLE_WRITER or MULTI_NODE_MULTI_WRITER).

But if a plugin cannot present the same volume on different nodes simultaneously (block storage) it must report as not supporting multi-node, because supporting multiple containers on the same node is not multi-node.

However, we do support mounting the same volume on the same node at different target_paths (to different containers). I would like to request a capability to say that a volume can be published to multiple containers on the same node. Perhaps we can add a new access mode named SINGLE_NODE_MULTI_ACCESS? Then the spec could be updated to indicate that the NodePublishVolume RPC could work when the volume has this capability.

jieyu commented 5 years ago

xref https://github.com/container-storage-interface/spec/pull/150

@rgcostea you can find some relevant discussion there.

I do believe there's need to introduce some access mode indicating if a volume can be published multiple times on a node or not. Depending on CO's implementation, some CO might prefer doing node publish just once, and use bind mounts for workloads. Some CO might decide to do call node publish multiple times, one for each workload.

I think the current status-quo is that all CO simply assumes that a volume can be published multiple times on a node for SINGLE_NODE capability volumes.

bswartz commented 5 years ago

@jieyu What you wrote above directly contradicts what the spec says (thanks to the language added in #150) Either the COs are violating the spec and we should change the COs, or else we need to reverse #150.