WIP: Managing Gluster block volumes

[aravindavk]

Updates: #912
Signed-off-by: Aravinda VK [email protected]

[atinmu]

Great start! While this document captures on the internals of the APIs and how the business logic will be implemented based on different conditions on available block volumes, size et all, it'd be awesome if we can have a design flow (mainly a diagram) which can illustrate the workflow above and underneath the GD2 layers to have a better grasp on the design for the beginners.

Thoughts?

[amarts]

Thoughts?

I guess, in none of these APIs, there is any role of GD2 at all. This provides 1-1 mapping between gluster-block-cli to a gd2 plugin API. (As already mentioned in doc).

Only change is, if there is no block-hosting-volume present, then it would create one. (And also see if the volume is full, create one more).

[amarts]

LGTM

[atinmu]

I guess, in none of these APIs, there is any role of GD2 at all. This provides 1-1 mapping between gluster-block-cli to a gd2 plugin API. (As already mentioned in doc).

Probably it's unfair to say that GD2 plugin API is not GD2's responsibility :-)

[aravindavk]

Probably it's unfair to say that GD2 plugin API is not GD2's responsibility :-)

As @amarts mentioned, this feature can be developed without changing glusterd2. Except the block hosting volume management all other steps can be done with Gluster mount(Can be outside the cluster).

Also, if we replace block cli commands with mount, mkdir and xfs quota, then it will become flex volume plugin. (If we replace block cli command with mount, loop device create then it will become loop dev plugin)

[amarts]

Probably it's unfair to say that GD2 plugin API is not GD2's responsibility :-)

Yes, and hence the discussion is going on @ gluster/gcs#40

Ideally, we would have done this as part of CSI driver itself, but as requested, if we keep the API similar to heketi in gd2, then we can actually write a single CSI driver which would work for both stack. Which means, it is much easier to validate if g-b works as same as current stack too.

This document, and work would be phase#1 of the work, and once things stabilize, and more well integrated, we may still have to move it out to CSI driver.

[obnoxxx]

@phlogistonjohn @raghavendra-talur Please review this!

[amarts]

Update for those who are reviewing, at the end of discussion in a meeting today, thought of doing all these as a separate project (or as a sub-process) of gluster-block came up. Which means that gluster-block plugin in plan itself can work as a solution to gluster/gluster-block#43 and also would solve the issue of having 'gluster-block CLI' as a separate process.

Happy to hear feedback.