[Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0

[Kaushal M]

I was away on a small vacation last week, so I haven't been able to
reply to this thread till now.

There has been quite some discussion while I was away. This kind of
discussion was exactly what we wanted.
I've read through the thread, and I'd like to summarize what I feel is
the general feeling shared by all.

- GlusterD has shortcomings in its store and membership functionality
and is in need of improvement.
This is the immediate goal that we were targeting. We started this
discussion because we did not want to start the development without
hearing what the community has to say.

- We'd like to move to using external utilities to manage some of the
things GlusterD currently does.
This is because we don't want to burden ourselves with creating new
implementations for doing tasks other tools do well already. This is
the reason for our exploration of consul. Consul does distributed
simple storage and membership well, and could replace the existing
store and peer membership mechanism as implemented in GlusterD.

- There is also a need to improve and build upon the current cluster
management facilities provided by GlusterD.
Users want to be able to do more using GlusterD than what is currently
possible. This, IMO, mainly is with regards to monitoring and
automation. Users want more information from GlusterD regarding the
cluster state, and want to run automated tasks based on the obtained
information. We'd like to move these kind of improvements away from
core GlusterD as well, and this is where the automation tools like
Puppet, Saltstack, etc. come in.

- Users want GlusterFS to remain easy to deploy
With the talk of all the external utilities, some users are concerned
GlusterFS is going to become hard to deploy, with even small
deployments needing lots of dependencies to be pulled in. This is a
something I am concerned with as well, as ease of deployment is one of
the notable characters of GlusterFS and we shouldn't lose it.

With these details in mind, I have an initial idea on how GlusterD-2.0
and GlusterFS-Quattro are going to shape up.

GlusterD will continue to exist and will do most of the functions it
performs today. Where ever possible it would delegate it's functions
to external utilities. We need to make sure that these external
utilities don't need any further configuration from the user to be
usable (how we are going to accomplish this is a problem on its own).
Retaining GlusterD in this way should satisfy the easy to deploy
character.
The higher level automation and monitoring capabilities will be
handled by tools like Puppet, Saltstack, Chef etc.  We would probably
need to pick one among these for initial community support. I have no
preference among these, but since we already have a puppet-gluster
module, I think Puppet would be the most likely choice. GlusterD would
be extended to provide more internal, cluster information to these
tools, for them to make their intelligent decisions.

The choice of programming language and external utilities we make,
will decide how hard achieving the above would be.

For the present we (GlusterD maintainers, KP and me, and other
GlusterD contributers) would like to start off GlusterD-2.0 by using
Consul for membership and config storage. The initial implementation
would probably only just have the minimum cluster management
functions, and would mainly be a POC or prototype kind of
implementation. We'll try to keep it clean and reusable for later. We
have been planning to use Go as the language of development, as we
believe it is easy for C developers to pick up and provides features
that make it easier to write distributed systems. There has been
another mail thread on the topic of language choices, which should
probably answer any questions on this decision.

What does the list think of my thoughts above?

~kaushal