Hi all,
Now that Heketi is focusing just on GlusterFS, we need to finalize the API. The implementation may or may not finish the entire API set, but it will need to do enough for Manila and Kubernetes to consume. Although the proposed API is quite simple, please make sure that the proposed API makes it easy to add future features.

Here is the proposed API:
https://github.com/heketi/heketi/wiki/API

Here is the old one for the prototype used by the demo:
https://github.com/heketi/heketi/wiki/API/c4be1ddcfd17e72117ebc584d646eec2987fcb58

Need to check if any of the ssh commands failed, and return accordingly

Setup SSH with ssh-agent, which I am guessing is probably the best method. In the configuration file highlighted by #19, it could point to a pem file.

When creating the bricks on a certain node, make sure to add the brick entry to fstab

Currently Heketi uses a simple Makefile to create a tar.gz distribution since it is written in Go. We may need to support an RPM so that it is installed with systemd support.

This may or may not accelerate the volume creation process

Look at Ceph calamari authentication

• Slave heketi servers connect to the master server.
• Any DB changes are sent to the hereto slaves
• Slaves are told order of who the next master is if the master dies.

Setup heketi as a systemd service

Line 195 in asynchttp_test.go and others like it should loop and wait for the async function to finish. It should not assume that it has finished already

Check if the glusterfs volume is running in the cluster. Return an error accordingly if it was in the db but not in the cluster.

May return a 202 HTTP code with a header url which points to the status of the request. Or could use web socket?

Volumes should show what state they are in: Started, Created, Stopped, Zombie (tried delete, but didn't work)

I see in create volume API, replica string is optional and the default nature is to create a 2 way replica volume which limits an user to have a plain distributed volume.

There is already logging in the middleware, but we need logging throughout Heketi

@lpabon Can you add some documentation on how you plan to use Swift's ring? From what I read about, ring seems to be Swift specific. How will heketi be hooking into it?

Since we know the number of drives being added to the ring at creation, calculate the correct partition power

There should be a new REST endpoint called /info which reports what the plugin is and any plugin information

Setup Auth0/JWT authentication middleware

JSON config file. It should have a section for the plugin to get its own configuration.