"it also has Zookeeper support etc." - just to correct this and remove the perception that LogCabin somehow requires Zookeeper or works with it. LogCabin as I understand is the C++ implementation of a small store based on the Raft consensus protocol - to provide a consistent and a small distributed store. The Zookeeper part is a RAMCloud thing for storing co-ordinator information to an external cluster and it does not come with LogCabin. -----Original Message----- From: gluster-users-bounces@xxxxxxxxxxx [mailto:gluster-users-bounces@xxxxxxxxxxx] On Behalf Of Prasad, Nirmal Sent: Friday, September 12, 2014 5:58 PM To: James; Krishnan Parthasarathi Cc: Balamurugan Arumugam; gluster-users@xxxxxxxxxxx; Gluster Devel Subject: Re: [Gluster-devel] Proposal for GlusterD-2.0 Has anyone looked into whether LogCabin can provide the consistent small storage based on RAFT for Gluster? https://github.com/logcabin/logcabin I have no experience with using it so I cannot say if it is good or suitable. I do know the following project uses it and it's just not as easy to setup as Gluster is - it also has Zookeeper support etc. https://ramcloud.atlassian.net/wiki/display/RAM/RAMCloud -----Original Message----- From: gluster-users-bounces@xxxxxxxxxxx [mailto:gluster-users-bounces@xxxxxxxxxxx] On Behalf Of James Sent: Friday, September 12, 2014 4:17 AM To: Krishnan Parthasarathi Cc: Gluster Devel; gluster-users@xxxxxxxxxxx; Balamurugan Arumugam Subject: Re: [Gluster-devel] Proposal for GlusterD-2.0 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-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
