Mike McGrath wrote:
On 1/2/07, Konstantin Ryabitsev <icon@xxxxxxxxxxxxxxxxx> wrote:
On 02/01/07, David Lutterkort <dlutter@xxxxxxxxxx> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
