[Bugs] [Bug 1294548] [RFE] Enhancement: The cli could manage state

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1294548

James (purpleidea) <jshubin at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |needinfo?(jshubin at redhat.co
                   |                            |m)



--- Comment #3 from James (purpleidea) <jshubin at redhat.com> ---
I had a short chat with JoeJulian about this, and I think I know what he's
getting at. If I were to rephrase his feature request in my language, what Joe
really wants is something like puppet-gluster, except way more powerful, so
that you "set the desired state" declaratively and something (puppet?) causes
your cluster to converge on this state.

I actually want the same thing, which is why I started puppet-gluster, however
I long realized that the puppet engine and language aren't going to be able to
accomplish that goal.

Joe's proposal of moving it into glusterd is actually very compelling, and
approximately the right thing to do, however I have an alternative idea which
is functionally identical. I've actually mentioned the idea to some different
gluster devs in the past, but my idea isn't quite ready for prime time yet.

What is it? Well, I'm building a prototype for a next generation config mgmt
engine and language. It might support a variant of the puppet language so that
existing code could be roughly compatible or easily portable, but this hasn't
been decided yet. It will depend on what the puppet folks have to say.

The engine part is the interesting part. I believe my engine is sufficiently
powerful that in addition to solving traditional configuration management
problems, we'll be able to "libify" it, so that traditional software (gluster,
ceph, freeipa, etc...) can write their management layer in native config mgmt
code, and not have to worry about getting that part right, since my engine will
offer common patterns as easy to use primitives.

In effect, my system could produce a "glusterd" binary. I'm actually writing
this prototype in golang, so this actually fits very nicely with accomplishing
this.

I'll probably have a full blog post about this with lots of code within a week
or two, but no later than a month from now.

Hopefully this will be something useful the gluster team would find useful.
It's not anywhere near being ready for production, so I'm not sure if this
would fit for a glusterd 2.0 timeline, but maybe it's enough to pique their
interest and devote some resources to my project in the hopes of later
benefiting theirs. I'm also hoping that my design and model are more compelling
and simpler to reason about than traditional glusterd code.

HTH,
James
@purpleidea

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.