Support for mounting the same volume on the same node by multiple workloads

[sbezverk]

According to the spec's table below:

	T1=T2, P1=P2	T1=T2, P1!=P2	T1!=T2, P1=P2	T1!=T2, P1!=P2
MULTI_NODE	OK (idempotent)	ALREADY_EXISTS	OK	OK
Non MULTI_NODE	OK (idempotent)	ALREADY_EXISTS	FAILED_PRECONDITION	FAILED_PRECONDITION

Plugin should fail on the second NodePublish request if a second workload tries to mount the same volume on the same node.

This is a valid use case for some containers orchestrators, the spec should not force this behaviour and it should be left for CO's plugin consideration.

[davidz627]

There are many valid and currently in-use use cases for consuming the same volume on multiple workloads on the same Node. The restriction outlined in the table above is an artificial one that is not an actual limitation of devices and therefore I agree that the spec should not force this limitation and leave it open for the SP to decide.

This change would also align with the current interpretation of access modes in Kubernetes which users are successfully using in production today.

[jieyu]

xref #150. Please see the discussion there.

I think the correct approach is to refine access mode so that we can explicitly distinguish plugins that only have single publish capability vs. those plugins that are single node but has multiple publish capability.

[j-griffith]

So IIUC this is like multiple containers on a single node; I think clearing things up to allow that is a good idea. There is a caveat there for non-shared FS scenarios that I think will be an issue but that's more of a user problem I think; or perhaps up to the driver to decide if they want to disable this ability for non-shared FS cases (long winded version of LGTM :) )
👍

[bassam]

In a Kubernetes scenario with RWM support, working around this restriction would require scheduling pods that share a volume on separate nodes. Why is this restriction needed?