On Fri, Mar 22, 2013 at 2:09 PM, Jeff Darcy
<address@hidden> 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 some caveats:
under its care. The best known example of such a coordination service
is Apache's ZooKeeper[1], 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[2] written in Go, Arakoon[3]
written in OCaml, ConCoord[4] 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 codebase?
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 code...).
Regards,
Vidar