Create CSI driver for gluster block

[humblec]

This issue handles the requirement for glusterblock CSI driver which is capable of performing below actions in its first version.

*) Create block volume
*) Delete block volume
*) Mount
*) Unmount
*) Documentation about how to use/test this driver.

This attempt has to be started with a design PR which describes the driver in detail.

• Which API's ( heketi, GD2, heketi/GD2) to use to provision block volumes.
• Volume create API
• Volume delete API
• Mount
• Unmount

[humblec]

iic, we dont have API's available for these functions in GD2.
Can we create issues for the same in GD2 repo.

Any voluntters ? @Madhu-1 @Aravinda @amarts

[JohnStrunk]

For when this gets going... @j-griffith is working on an iSCSI library for use in CSI drivers. Currently there is nothing public, but there should be something in the next week or two.

[humblec]

@Madhu-1 has agreed to work on this. Assiging to @Madhu-1

[humblec]

@JohnStrunk Thanks ! yeah, he is working on it and we could consume the librabry in the driver.

[humblec]

/assign @Madhu-1

[sankarshanmukhopadhyay]

When the issues are filed on gd2, please list them here for reference.

[humblec]

@JohnStrunk @amarts do we have an issue in gd2 repo for gluster block API's to provision volumes ?

[humblec]

Eventhough we are not targetting this for first release of GCS , are we on agreement that, to which API ( GD2, Heketi or both) this block CSI driver should be talking to ?

[JohnStrunk]

Can this follow the same model as gluster file (i.e., shared code, but separate drivers to get both) and use the refactoring that will be a part of #64?

[amarts]

gluster/glusterd2#912 talks about gluster-block porting work for GD2!

But here is my proposal! Let me know if it makes sense!

As we are doing the CSI work for block, instead of using APIs provided by heketi or GD2, why can't CSI driver itself deal with doing the block provisioning and mounting? Now with 1.11 APIs we already have iSCSI mounts possible in CSI drivers. That way, picking either GD2 or GD1 API for block-hosting-volume based on just parameter in storageClass, All other code would remain same in both CSI code.

That way, we reduce lot of duplication work, and save the whole block porting effort for GD2. For stand-alone Gluster users, we don't need GD2 porting, because gluster-block already provides its own CLI..

Let me know if it makes sense!

@obnoxxx @humblec @Madhu-1 @raghavendra-talur @JohnStrunk @aravindavk

[obnoxxx]

@amarts I am not sure I fully understand the proposal:

A gd1 based CSI driver would be using the heketi apis for high-level block volume provisioning with block hosting volume management etc. So it would be similarly trivial to the glusterfs file volume provisioner. I think you are suggesting to put the higher level block-volume logic (at least for the gd2 world) into the CSI driver itself. That would be an entirely different CSI driver, much bloated compared to the other ones.

Saying that the gluster-block CLI already exists is not the main point here, I think: Heketi provides a high level API and cli on top of that, similar to high level (IVP) vs low level gluster volume api/cli. So in my plan, we would initially add the high level block volume functionality into gd2 as a plugin (or so). This would (probably) initially talk to gluster-block cli in the backend but provide the level of logic that currently heketi provides (and that you propose to move into csi). Then the CSI drivers for block for gd2 and heketi would be very similar with huge code share like in the file volume case. In a later step, we could integrate the functionality of gluster-block(d) into gd2 at a lower layer, and then we'd have the low and high level CLI and API nicely in one place. Very analogous to high lvl and low lvl volume API/CLI.

And again here: I think doing PRs with design docs instead of scattered design discussions in issues would have advantages. Example: https://github.com/gluster/gluster-kubernetes/blob/master/docs/design/gluster-block-provisioning.md

Here is the comment that I made to the gcs issue:
gluster/gcs#40 (comment)