[Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0

[Prasad, Nirmal]

"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 at gluster.org [mailto:gluster-users-bounces at gluster.org] On Behalf Of Prasad, Nirmal
Sent: Friday, September 12, 2014 5:58 PM
To: James; Krishnan Parthasarathi
Cc: Balamurugan Arumugam; gluster-users at gluster.org; Gluster Devel
Subject: Re: [Gluster-users] [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 at gluster.org [mailto:gluster-users-bounces at gluster.org] On Behalf Of James
Sent: Friday, September 12, 2014 4:17 AM
To: Krishnan Parthasarathi
Cc: Gluster Devel; gluster-users at gluster.org; Balamurugan Arumugam
Subject: Re: [Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0

On Fri, Sep 12, 2014 at 12:02 AM, Krishnan Parthasarathi <kparthas at redhat.com> wrote:
> ----- Original Message -----
>> On Thu, Sep 11, 2014 at 4:55 AM, Krishnan Parthasarathi 
>> <kparthas at redhat.com> 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 at gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
Gluster-users at gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users