search

container-storage-interface / spec

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

Support for user options on creation #369

Closed lpabon closed 4 years ago

lpabon commented 5 years ago

Overview

In Kubernetes, in-tree drivers had access to user request in the PVC. Now with CSI, plugins no longer can get configurations from the user supported by the back end storage system. Although the CSI specification does not itself block this information from being in a CreateVolume call, it also does not specify clearly how it can be provided by the CO.

Proposal

Users requesting storage from Kubernetes, Mesos, Nomad and other COs can pass information to the CO according to their user interface model. The CO would then take this information, and pass it down to the driver.

This could be done in a number of different ways. One way would be to add a new field in CreateVolume which clearly states that the information is coming from the user, which could be a map <string, string>.

jdef commented 5 years ago

Can you please list concrete use cases that you're solving for with this generalized solution?

E.g. volume anti affinity

Akrog commented 5 years ago

I think user information and when it can/should be passed to plugins is something that should be handled at the CO level, as there could be policies where only certain users are allowed to do this, or in k8s only some Storage Classes.

The CO should make the decision on whether this info should be passed or not, and if it should then add it to the existing parameters field on CreateVolumeRequest.

For k8s it should get the info from the PVC and add it to the parameters following whatever rules they consider necessary (ie: StorageClass must set a flag to allow it, or some other thing).

During the meeting it was mentioned that the problem is that the k8s community does not want to implement it, and adding it to the CSI spec is a "shortcut" to resolve the issue. In my opinion adding things to the spec on CO convenience even when there's no sound technical reason is a slippery slope.

Before Kubernetes removes in-tree storage drivers, and use their CSI counterparts, they should have feature parity (as pointed out in the overview), and they can do it today with CSI spec v1. No need to change the spec for this.

One of the use cases presented in the meeting for this was affinity/anti-affinity, but I think that should be its own thing (https://github.com/container-storage-interface/spec/issues/44).

There were some other cases, but I didn't hear (maybe I missed it) any case that would not be resolved with the parameters field or that would not be appropriate to pass as them there.

lpabon commented 4 years ago 
Decision: Instead of opening a hole in the API and encouraging breaking portability, let’s
work with CSI community to add functionality. Those who really want to do this can fork
the Kubernetes sidecar containers (but we shouldn’t encourage that behavior by default).

From Minutes