oep(csi provisioning): add proposal for csi based volume provisioning #2617
Conversation
AmitKumarDas
requested review from
kmova,
mittachaitu,
payes,
prateekpandey14,
shubham14bajpai,
sonasingh46,
utkarshmani1997 and
vishnuitta
AmitKumarDas
force-pushed
the
oep-csi
branch
2 times, most recently
from
7dd3daa to
1e2542f
Compare
AmitKumarDas
changed the title
AmitKumarDas
force-pushed
the
oep-csi
branch
3 times, most recently
from
8ab08b7 to
f6041fc
Compare
There was a problem hiding this comment.
@AmitKumarDas have provided some review comments, additionally it will be very helpful if you provide architectural diagram of proposed changes and a comparison with the existing approach will be very helpful in understanding the need.
|
|
||
| There were previous attempts to implement CSI which is tightly coupled with the | ||
| way Kubernetes works. This attempt will revisit to have an implementation that | ||
| is not tied to Kubernetes native resources. |
There was a problem hiding this comment.
I can't relate this "is not tied to kubernetes native resources", as CSI itself is something that is tightly coupled with kubernetes (requires kubernetes APIs).
There was a problem hiding this comment.
CSI abstracts container orchestrators.
An Ideal CSI implementation should work with any container orchestrator e.g. mesos or k8s or nomad, etc
There was a problem hiding this comment.
in other words, how new approach will solve this ?
| way Kubernetes works. This attempt will revisit to have an implementation that | ||
| is not tied to Kubernetes native resources. | ||
|
|
||
| Current provisioning approach works well given day 1 operations. However, we |
There was a problem hiding this comment.
what are day1 and day2 operations ?
|
|
||
| #### Proposed Implementation | ||
| Since OpenEBS itself runs on Kubernetes; limiting OpenEBS provisioning | ||
| to be confined to CSI standards will prove difficult to develop and improve upon |
There was a problem hiding this comment.
what is the difficulty with the current approach ?
| to be confined to CSI standards will prove difficult to develop and improve upon | ||
| OpenEBS features. | ||
|
|
||
| This proposal tries to adhere to CSI standards and make itself CSI compliant. |
There was a problem hiding this comment.
Link to CSI standards will be helpful
|
|
||
| This proposal tries to adhere to CSI standards and make itself CSI compliant. | ||
| At the same time, this proposal lets OpenEBS embrace use of Kubernetes custom | ||
| resources and custom controllers to provide storage for stateful applications. |
There was a problem hiding this comment.
above sentence and "Inorder to implement CSI as per its standards, OpenEBS volumes should decouple
itself from being aware of container orchestrator." are bit confusing, custom resources and CSI are native to kubernetes, what kind of decoupling we want to achieve?
Will CSI work for other orchestrator's also without or with little modification ?
There was a problem hiding this comment.
CSI is not native to Kubernetes.
OpenEBS needs to implement CSI on one hand, however since OpenEBS itself runs on Kubernetes, it will depend on Kubernetes features. Due to this dependency current OpenEBS implementation for CSI has deviated from just being compliant with existing methods and payload defined by CSI.
This proposal is an attempt to adhere to CSI standards as well as not limit OpenEBS implement its features (read Kubernetes curstom resources and controllers)
I shall add a FAQ section in this proposal.
| name: <some name -- can be same as storage class name> | ||
| namespace: <namespace of openebs i.e. openebs system namespace> | ||
| spec: | ||
| controllerDeployment: |
There was a problem hiding this comment.
controller is a generic word. Should we change this to target?
AmitKumarDas
force-pushed
the
oep-csi
branch
9 times, most recently
from
c6fb2e4 to
92d0bc3
Compare
| #### Delete the volume | ||
| As an application developer I should be able to delete the volume that was being | ||
| consumed by my application. This volume should get deleted only when the | ||
| application is deleted. |
There was a problem hiding this comment.
Should it be something like:
This volume can be deleted only after the application consuming it has been deleted.
This commit adds an OpenEBS Enhancement Proposal to define the specifications and design required to implement CSI driver for OpenEBS based volumes. Signed-off-by: AmitKumarDas <amit.das@mayadata.io>
AmitKumarDas
changed the title
This commit adds an OpenEBS Enhancement Proposal to define the specifications and design required to implement CSI driver for OpenEBS based volumes.
Signed-off-by: AmitKumarDas amit.das@mayadata.io