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

[James]

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