[Gluster-devel] Glusterd: A New Hope
vidar at hokstad.com
Mon Mar 25 09:38:29 UTC 2013
After reading through this thread, I feel compelled to make some comments.
I'm a user.
On Fri, Mar 22, 2013 at 2:09 PM, Jeff Darcy <jdarcy at redhat.com> wrote:
> During the Bangalore "architects' summit" a couple of weeks ago, there
> was a discussion about making most functions of glusterd into Somebody
> Else's Problem.
I see a number of complaints about this as some sort of admission of
failure. I agree with the above to an extent - as a user I'd much rather
you focus on what makes Gluster unique rather than reinvent the wheel. With
> under its care. The best known example of such a coordination service
> is Apache's ZooKeeper, but there are others that don't have the
> noxious Java dependency
I'm happy you recognise the issue of Java. I'd see having to drag that
around as a major barrier. One of the major benefits of glusterfs is the
simplicity of deployment compared to many alternatives, and that benefit
would be massively diminished if I needed to deal with a Java dependency.
> - e.g. doozer written in Go, Arakoon
> written in OCaml, ConCoord written in Python. These all provide a
> tightly consistent generally-hierarchical namespace for relatively small
> amounts of data. In addition, there are two other features that might
> be useful.
I like the Gluster on Gluster idea you mention later on. Apart from that,
have you considered pulling out the parts of Glusterd that you'd like to be
able to ditch and try to generalize it and see if there'd be any interest
in it as a standalone project? Or is too much of what you're looking for
new functionality that is not already covered by part of your current
Also, a cluster coordination service using Gluster as the storage would
appeal to me for other uses (in fact, we've considered doing just that
because of the simplicity).
> * Membership: a certain small set of servers (three or more) would be
> manually set up as coordination-service masters, e.g. via "peer probe
> xxx as master").
Careful here. Again, a big advantage of Gluster to users is to not need any
"special" servers that require other treatment. I recognise there's a
bootstrap problem, but to whatever extent possible, at the very least try
to make this transparent to users (e.g. have the cluster automatically make
more of the nodes take on coordination-service roles if any are lost etc.).
> In conclusion, I think our best (long term) way forward would be to
> prototype a doozer-based version of glusterd. I could possibly be
> persuaded to try a "gluster on gluster" approach instead, but at this
> moment it wouldn't be my first choice. Are there any other suggestions
> or objections before I forge ahead?
Of the alternatives you list, I'd prefer Doozer as well from what little
I've seen, for reasons of simplicity (minimal extra runtime dependencies as
well as a language I don't hate in case I'd ever need to do anything to the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel