On 03/25/2013 02:44 PM, Alex Attarian wrote:
where do you get the idea that I'm against glusterd? I'm perfectly fine with 3.x versions, those are still maintainable. But if you want to add Zookeper now, on top of Java requirement, where is it going to end?
I explicitly rejected ZK because of the Java requirement. That kind of complexity and resource load just can't be hidden from the users.
Yes re-inventing is not the best thing, but sometimes it can be much worse to add a 3rd party component with some strenuous requirements than re-iventing. Right now things are very easy to maintain in any of the 3.x versions, right inside glusterd.
I certainly don't think so. A simple "volume set" command might generate dozens of RPC messages spread across several daemons using multiple RPC dispatch tables, with state machines and validation stages and all sorts of other complexity. Finding out where in all that a command died can be *very* challenging. Debugging problems from nodes having inconsistent volfiles because one died in the middle of that "volume set" command can be even worse. I wouldn't call that maintainable.
Why not keep that? Even all these other functionalities that others want and you really want to implement for scalability and flexibility, they could all be built with your cluster on gluster solution. I really don't want to worry about Zookeeper or Doozer when I run gluster.
You shouldn't have to. Even if we were to use one of those - and the whole point of this discussion is to explore that along with other alternatives - it wouldn't be exposed as a separate service. It would be embedded within glusterd, started and stopped when glusterd itself is, etc. Yes, developers might need to learn to navigate some new code, but they would in any event and users/administrators shouldn't care at all. To them it would be the same CLI as before, producing logs and other artifacts that are if anything more comprehensible than today.
I'm still not opposed to the "GlusterFS on GlusterFS" approach instead, but it has its own issues that need to be worked out. Maybe someone who prefers that could sketch out a way to do that without having to retain all of glusterd as it is now to manage that special config volume (which obviously can't rely on the same services it provides). There'd still be more layers, there'd still be more daemons to manage, and it seems like there'd be two sets of code doing essentially the same thing at different levels.
