Config stuff and glump (as my introduction)

[Michael DeHaan]

Mike McGrath wrote:
> On 1/2/07, Konstantin Ryabitsev <icon at fedoraproject.org> wrote:
>> On 02/01/07, David Lutterkort <dlutter at redhat.com> wrote:
>
>> Sure, but I try to avoid using tools that I can't fix, especially
>> tools that are integral to the functioning of my systems. Especially
>> since it's the ONLY tool that requires ruby.
>
> I have to say this is a pretty big minus, not only do we not have ruby
> installed anywhere in our environment that I'm aware of but for the
> most part we're a python shop.  It's still not a no for puppet, just a
> big strike against in my mind.

I've always been disappointed when I've run across the "but we're a X 
shop" thing in my career.    They've usually ruled out
good tools for the wrong reasons.    Namely, "but we're a Windows shop, 
we can't do that", "we're a Sybase shop, we can't use Postgres", "we are 
going to be a .NET shop, no Python for you!".

Python is great, but Ruby can be great also.   To a person that has a 
lot of experience with various dynamic languages, they aren't really all 
that different,
at least when you get beyond Perl and "I have to hack in an object 
system!?!?".   But hey, even /that/ isn't all that hard.   They are both 
very simple languages to learn.   Rails became famous because of it's 30 
minute tutorial/demo, for instance.   At worst case, you get another 
language to add to your resumes.

If it you think chosing Puppet will be a problem due to implementation, 
at least know you have a couple of folks here who are fluent
in Ruby and aren't put off by it, and are willing to help out should 
that become a problem.   David's pretty darn active in the Puppet 
community and I think you're going to see a lot more interesting plugins 
for it coming up in the future.  I myself do not follow Puppet closely, 
but I have the Ruby knowledge to work on it and extend it if needed.    
Do I expect that I'll need to work on it?   Not really. 

The comment about certain libraries not having Ruby bindings is 
definitely valid, though in many cases the tools in question have 
command line forms that are preferable to the API's in almost every 
case, and Ruby is excellent at interacting with them.   Cobbler 
(http://cobbler.et.redhat.com) is written in Python, for instance, but 
chooses to call a lot of tools directly just because the Python API's 
are complex and shifting compared to their command line equivalents.   
It's much easier to just rely on the external interfaces.   Yes, it's 
gluey, but that's what 90% of systems programming ends up being.   While 
one can say they don't want to learn Ruby, I really don't want to know 
the yum and RPM api's inside and out either.   So I think that's a bit 
of a push to say there are a ton of Python libraries a config management 
app needs to connect to.   A few, yes, but what functionality there is 
needed that isn't already there?   There can't be that much.

Another danger with a less-used solution is that you have a smaller user 
community, so you miss out on features and have less community folks 
available to fix things should they go wrong.    If one adds new 
features, one can contribute those back upstream.   Plus, it makes the 
knowledge learned from working on it portable -- not just useful for 
infrastructure, but in other projects, which is an honorable goal.   
Laziness is a virtue according to Mr. Wall, so I'm all for the solution 
that involves the least amount of work and best future support for 
things that need to get done, as opposed to the one that is fun and will 
create more work in the future.

But then again, I'm new, and I don't entirely know what needs to get 
done.   My two cents, anyway...

--Michael

>
>                 -Mike
>
> _______________________________________________
> Fedora-infrastructure-list mailing list
> Fedora-infrastructure-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list