2.0 Tracking Issue

[bswartz]

This issue is to collect ideas for an eventual 2.0 release of the CSI spec. This issue in no way suggests we plan to address any of these ideas, or that a 2.0 release will ever happen. Rather, the intention is to collect ideas that would be very difficult to implement in a 1.x release because they can't be made backward compatible, such that if we ever did do a 2.0 release, we would want to implement as many of these ideas as possible in that release to avoid needed a 3.0 later on.

[bswartz]

The SINGLE_NODE / MULTI_NODE distinction in the access modes is and how they are handled in NodePublishVolume()
completely contrary to what Kubernetes actually wants. The documentation for SINGLE_NODE / MULTI_NODE matches what would be useful semantics for Kubernetes, but the documentation for NodePublishVolume() then says the opposite thing (basically saying that supporting more than one pod requires MULTI_NODE). To fix this in 1.0 would require adding new access modes and deprecating the existing ones, and updating NodePublishVolume() to interpret the new access modes in the way we actually want. A capability bit would need to be exposed to COs to detect if the SP supported the new access modes so Kubernetes could use them. All of that is far more gross than just rolling a 2.0 version with different semantics for NodePublishVolume() with regard to access modes. We could add new access modes in a 2.0 that correspond to the existing behavior in the unusual case that someone would want that.

[bswartz]

There is some reworking we would want to do around resize if we had a 2.0 version. In particular, cloning volumes from snapshots or other volumes and making them larger at the same time should have been tied to the resize functionality so that COs could leverage existing filesystem-resize workflows rather than forcing the SPs to have 2 different ways to expand filesystems (one for explicit expand operations, and another for clone-to-larger-size).