Heketi-based CSI driver

[JohnStrunk]

Describe the feature you'd like to have.
There should be a CSI driver that works with Heketi so that users who have not yet moved to GD2 can benefit from CSI.

What is the value to the end user? (why is it a priority?)
The current gluster-file CSI driver is targeted at GD2, but many users have not started using gd2 in their environments. By having a CSI driver that targets Heketi, users can get the benefits of the standard CSI interface without also needing to migrate to the new gluster management daemon.

How will we know we have a good solution? (acceptance criteria)

• The driver will support at least basic CSI functionality of (de-)provisioning & (un-)mounting.
• The driver will build as a separate executable in a separate container from existing drivers so that it can be installed, upgraded, and patched independent of other CSI drivers in this repo.
• There should be maximal sharing of code between this and the gd2 driver to gain benefits for bug elimination and testing.
• The resulting code should not contain conditionals based on gd2 or heketi. Proper modularization and the separate entry points of the drivers should be sufficient to distinguish code paths.

Additional context

• This driver and associated refactoring will be handled in a dedicated branch to be merged back periodically.
• For CI testing, this depends on Add Travis CI job #53

[JohnStrunk]

The refactoring here may also contribute toward #7

[humblec]

This work will be progressed against heketi-csi branch in this repo. Once its in shape, the PR will be up against master.

[jarrpa]

@humblec and I have started collaborating at the following branch: jarrpa@86bb8ed

We will be pushing commit to the heketi-csi in short order. Speaking of, @humblec oe @JohnStrunk , I don't think I have write access to that branch. Any help to remedy that would be appreciated.

[obnoxxx]

@jarrpa that's a commit really, here's the more invariant branch: https://github.com/jarrpa/gluster-csi-driver/commits/heketi-support :-)

[JohnStrunk]

I don't think I have write access to that branch. Any help to remedy that would be appreciated.

I'm not sure where the switch would be... You have write access to the repo, and the branch isn't protected. May just want to go w/ PRs unless you know where the magic is.

[obnoxxx]

Having personal repos and mutually rebasing should also be good enough. It's common practice. Eventually stuff needs to land in the master branch in PRs anyway. So we can start percolating preparatory patches out into master from personal forks as well as from a branch in this repo, imho, but no strict need to wait and have it all completely ready and submit it in one giant PR if there's useful stuff to be had from the finished prep work. My 2 cents...

[blurpy]

Any progress on this? :)

[JohnStrunk]

I'm not aware of any plans to take this forward. Sorry.

[blurpy]

OK. I'm having a hard time finding updated information about GD2. The repo hasn't been updated in months and release notes for Gluster 5 calls it experimental, while release notes for Gluster 6 says the focus has shifted and that's about it. Does that mean this driver can not be used for production?

[JohnStrunk]

At the current time, I would not recommend this for production usage.

@amarts Can either point you to a current roadmap for Gluster or provide an update.