|
From: | Anand Avati |
Subject: | Re: [Gluster-devel] Early review/feedback for glusterfs 4.0 plan |
Date: | Thu, 12 Dec 2013 15:33:43 -0800 |
Thanks... I just read your 4.0 doc. I have a few comments:
1) Someone talked to me a bit about the sub bricks idea. I haven't
decided how awesome or not this would be, but I'm feeling positive
about the change. See 2b for a related comment. I'm keen to see
Gluster gaining an understanding of "tiered" storage.
2) I wasn't sure if I understood certain parts correctly. Depending on
if I did or didn't, I think there may or may not be some significant
problems with the suggested model for building higher level management
tools (eg: puppet-gluster). I would have to know more to know for
sure. For one, I got the feeling that some commands needed to be
executed one after another in a certain order...
2b) If someone can help with the algorithms I mentioned in:
https://lists.gnu.org/archive/html/gluster-devel/2013-11/msg00135.html
I think I'll be able to provide a convincing case that Gluster
management isn't as bad as you might be alluding to in your 4.0
comments. I think a lot of the GlusterFS core team are allergic to
Puppet. I think this is quite normal, because Gluster core is super
low level C, where as Puppet (a mostly declarative language) is super
high level and on the opposite side of this spectrum. However, I think
most people are discounting the importance of having something like
this. The future is _all_ configuration management. The early adopters
are almost mostly there.
3) Between early Gluster x.y and 3.x I had to completely change
Puppet-Gluster to support the new management style. The current
Puppet-Gluster stuff is easily one of the most complicated Puppet
modules that exists _anywhere_! This is partly due to the fact that
while Gluster might be easy to manage (and even logical) for a human,
it is _not_ from an automation point of view.
In any case, I've built
it, but there are certainly ways that Gluster internal could make it
easier (thank goodness for --xml anyways ;))
If Gluster 4.0 radically breaks all the work I've done for current
Puppet-Gluster, I really won't have any desire to rewrite all of this
for a third time without a large pay cheque from RedHat. On the plus
side, this could be a good way to get rid of me ;) Either way, whether
you consult with me, or you consult with a different configuration
management expert, do the smart thing: find out if the management
style you're proposing is compatible with configuration management. If
it will work elegantly with Puppet, it will work for Chef, etc...
Usually when something "fits" really well with well designed Puppet,
it's a sign that the thing was designed _extremely well_.
As an example of this, the FreeIPA team (RedHat) did a kick ass job
putting together the FreeIPA management interfaces, and as a result,
it is extremely pleasant to use natively, and also with Puppet.
Example: https://github.com/purpleidea/puppet-ipa
4) Looking forward to 4.0 ! I hope I have a chance to see the going
ons very early, while there's still a chance for me to have a positive
influence on the external interfaces.
Happy hacking
Hope my comments are helpful/useful,
James
PS: I know that some at RedHat and Gluster core will probably think
this is insane, but think about it: In the future (maybe that's now)
software will ship natively with some sort of (probably mostly
declarative) "front end" as the recommended UI for management. This
means it makes sense to have some interfaces in native code, and some
as higher level abstractions around your native interfaces. Think of
the analogy of Gluster in C, but perhaps glusterd in higher level
python. Now realize that the "next level" might be something like
Puppet. I think it's already possible, when you include some of my
Puppet hacks, Example: https://github.com/purpleidea/puppet-pushing
[Prev in Thread] | Current Thread | [Next in Thread] |