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 _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
