On Fri, Sep 12, 2014 at 12:02 AM, Krishnan Parthasarathi <kparthas@xxxxxxxxxx> wrote: > ----- Original Message ----- >> On Thu, Sep 11, 2014 at 4:55 AM, Krishnan Parthasarathi >> <kparthas@xxxxxxxxxx> wrote: >> > >> > I think using Salt as the orchestration framework is a good idea. >> > We would still need to have a consistent distributed store. I hope >> > Salt has the provision to use one of our choice. It could be consul >> > or something that satisfies the criteria for choosing alternate technology. >> > I would wait for a couple of days for the community to chew on this and >> > share their thoughts. If we have a consensus on this, we could 'port' >> > the 'basic'[1] volume management commands to a system built using Salt and >> > see for real how it fits our use case. Thoughts? >> >> >> I disagree. I think puppet + puppet-gluster would be a good idea :) >> One advantage is that the technology is already proven, and there's a >> working POC. >> Feel free to prove me wrong, or to request any features that it's missing. ;) >> > > I am glad you joined this discussion. I was expecting you to join earlier :) Assuming non-sarcasm, then thank you :) I didn't join earlier, because 1) I'm not a hardcore algorithmist like most of you are and, 2) I'm busy a lot :P > > IIUC, puppet-gluster uses glusterd to perform glusterfs deployments. I think it's > important to consider puppet given its acceptance.What are your thoughts on building > 'glusterd' using puppet? I think I can describe my proposal simply, and then give the reason why... Proposal: glusterd shouldn't go away or aim to greatly automate / do much more than it does today already (with a few exceptions). puppet-gluster should be used as a higher layer abstraction to do the complex management. More features would still need to be added to address every use case and corner case, but I think we're a good deal of the way there. My work on automatically growing gluster volumes was demo-ed as a POC but never finished and pushed to git master. I have no comment on language choices or rewrites of glusterd itself, since functionality wise it mostly "works for me". Why? The reasons this makes a lot of sense: 1) Higher level declarative languages can guarantee a lot of "safety" in terms of avoiding incorrect operations. It's easy to get the config management graph to error out, which typically means there is a bug in the code to be fixed. In this scenario, no code actually runs! This means your data won't get accidentally hurt, or put into a partial state. 2) Lines of code to accomplish certain things in puppet might be an order of magnitude less than in a typical imperative language. Statistically speaking, by keeping LOC down, the logic can be more concise, and have fewer bugs. This also lets us reason about things from a higher POV. 3) Understanding the logic in puppet can be easier than reading a pile of c or go code. This is why you can look at a page of python and understand, but staring at three pages of assembly is useless. In any case, I don't think it's likely that Gluster will end up using puppet, although I do hope people will think about this a bit more and at least consider it seriously. Since many people are not very familiar with configuration management, please don't be shy if you'd like to have a quick chat about it, and maybe a little demo to show you what's truly possible. HTH, James > > The proposal mail describes the functions glusterd performs today. With that > as a reference could you elaborate on how we could use puppet to perform some > (or all) the functions of glusterd? > > ~KP _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
