After reading through this thread, I feel compelled to make some comments. I'm a user.<br><br><div class="gmail_quote">On Fri, Mar 22, 2013 at 2:09 PM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">During the Bangalore "architects' summit" a couple of weeks ago, there<br>
was a discussion about making most functions of glusterd into Somebody<br>
Else's Problem.</blockquote><div><br></div><div>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:</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">under its care. The best known example of such a coordination service<br>
is Apache's ZooKeeper[1], but there are others that don't have the<br>
noxious Java dependency</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - e.g. doozer[2] written in Go, Arakoon[3]<br>
written in OCaml, ConCoord[4] written in Python. These all provide a<br>
tightly consistent generally-hierarchical namespace for relatively small<br>
amounts of data. In addition, there are two other features that might<br>
be useful.<br></blockquote><div><br></div><div>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? </div>
<div><br></div><div>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).</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Membership: a certain small set of servers (three or more) would be<br>
manually set up as coordination-service masters, e.g. via "peer probe<br>
xxx as master").</blockquote><div><br></div><div>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.). </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In conclusion, I think our best (long term) way forward would be to<br>
prototype a doozer-based version of glusterd. I could possibly be<br>
persuaded to try a "gluster on gluster" approach instead, but at this<br>
moment it wouldn't be my first choice. Are there any other suggestions<br>
or objections before I forge ahead?<br></blockquote><div><br></div><div>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...).</div>
<div><br></div><div>Regards,</div><div>Vidar</div><div><br></div></div>