Config stuff and glump (as my introduction)

[Konstantin Ryabitsev]

Hello, all:

I've been recently invited to join this list, seeing as I'm the
original author of Glump (currently maintained by Seth), and also
because I'm currently in a similar situation trying to figure out what
to use for system config management here at McGill (I was recently
made sysadmin again after being a PHP monkey for over a year).

Now, I've not touched glump since mid-2005, and it's changed a bit
since then. I do hate cfengine (probably party due to the way it's set
up here), and I do not consider puppet to be a good alternative,
mostly because it's "yet another config language" and because it's
written in ruby. To use puppet, I'd have to learn "yet another config
language" and ruby, which is prohibitively time-consuming.

I've not yet had time to investigate bcfg2, but I will in the near
future. However, I'm wondering if I could use and extend glump to do
all I need -- will probably be the simplest. :)

I'm currently wondering how much pain it would be to write a trac
plugin that would do the same thing glump currently does. That should
give me an infrastructure with an extensive access to SVN and db for
versioning purposes, and built-in documentation/ticketing system.
Since trac provides POST-handing, I could also do stuff like edit
config files on the system to the point where they are working, and
then "bless" them to be uploaded, committed to svn, and be immediately
available to all members of that system group (unless that file is
managed by a glump-like system).

Now, this is pure vapourware. :) The only reason I'm interested in
implementing this is because we already use trac extensively, and
because writing plugins for it is pretty simple. I will probably start
out with just writing a glump plugin that will use the svn repository
to hold glump configs and sources, and then go on from there.

If you guys are interested in glump, would you also be interested in a
"trac-ified" glump? I plan to start working on this as soon as next
week.

Cheers and happy new year,

[David Lutterkort]

On Tue, 2007-01-02 at 16:19 -0500, Konstantin Ryabitsev wrote:
> To use puppet, I'd have to learn "yet another config
> language" and ruby, which is prohibitively time-consuming.

There is absolutely no reason why a puppet user would need to know ruby
- there are plenty of people who use puppet and have no ruby knowledge.

As for having to learn another config language vs. extending glump: you
can master puppet's language in a couple of hours or so. You would need
to weigh that against how long it would take you to extend glump to do
what you need it to do.

David

[Konstantin Ryabitsev]

On 02/01/07, David Lutterkort  wrote:
> There is absolutely no reason why a puppet user would need to know ruby
> there are plenty of people who use puppet and have no ruby knowledge.

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. On the other hand, I know
Python, and so does nearly every other person whom I'm likely to
consult if I have troubles with something. RHEL/Fedora use Python
extensively, and sometimes exclusively, so integrating a Python tool
with them would be very simple and straightforward. Many libraries
have bindings to Python -- very few have bindings to Ruby.

It doesn't make sense for me to rely on Ruby. Simple as that.
> As for having to learn another config language vs. extending glump: you
> can master puppet's language in a couple of hours or so. You would need
> to weigh that against how long it would take you to extend glump to do
> what you need it to do.

Yes, but at least it would be fun, considering I already did most of
the work with glump in the first place.

Regards,

[Mike McGrath]

On 1/2/07, Konstantin Ryabitsev  wrote:
> On 02/01/07, David Lutterkort  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.

-Mike

[Michael DeHaan]

Mike McGrath wrote:
> On 1/2/07, Konstantin Ryabitsev  wrote:
> > On 02/01/07, David Lutterkort  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
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list

[Toshio Kuratomi]

On Tue, 2007-01-02 at 21:40 -0600, Mike McGrath wrote:
> On 1/2/07, Konstantin Ryabitsev  wrote:
> > On 02/01/07, David Lutterkort  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.

This is a minus but I'm not sure it's the huge minus that everyone makes
it out to be.  I have several reasons for thinking that:

Why do we need to hack the tool?
* We'd need to hack puppet if we ran into a bug and the upstream
developers weren't very responsive.  With an active and responsive
upstream this is _less_ of an issue.  In some ways, this is like the
open source vs closed source argument for managers.  Just because the
manager can't hack on it doesn't mean there aren't other people who are
willing to because it's open source.  Similarly, just because we aren't
ruby gurus doesn't mean that there isn't a dedicated community of
hackers surrounding puppet. 
* We would need to hack puppet if it doesn't have features that we need.
We're currently moving from an extremely simple system.  It should be
pretty easy to determine if puppet will suit our present needs.  We also
want to allow room to grow.  For that we should be comparing puppet's
features to its competitors.

Would it be any easier to hack on if it were (C|shell|perl)?
* If it were written in C we'd all be capable of hacking on it but
wouldn't have much fun or be as productive as in python.  Ruby isn't
python but it shares a lot more with it than with C.  I learned python
by staring at other people's source code.  It's not so far fetched to do
the same thing with ruby.

Are we really devoid of ruby hackers?
* David, at least is quite knowledgable, not only with ruby but also
with puppet but I don't know how much time he has to spend with us.  He
is the maintainer of our FE package, though, so fixing bugs is something
he'll be keen to do for more than just us.
* puppet is being used in other areas of Red Hat, are there other Fedora
Infrastructure people (from outside of Red Hat as well as inside) who
are ruby/puppet hackers?

-Toshio

[Michael DeHaan]

Toshio Kuratomi wrote:
> puppet is being used in other areas of Red Hat, are there other Fedora
>
> Infrastructure people (from outside of Red Hat as well as inside) who
> are ruby/puppet hackers?

In case it wasn't clear, I'm also a Ruby user, and have been using it 
for various things for a few years.
Primarily for build system work (one system based on DamageControl, 
which is Ruby, one not), a couple of
rails apps, and some random customer and internal utilities (pre Red 
Hat).    I've also written some C binding
stuff for OpenGL should anyone _really_ want to go off the deep end (not 
hard, really, the Ruby DL module
rocks).   Basically I've used it for anything someone typically uses 
Perl for (XML parsing included), and I think
I even wrote some libpcap stuff in Ruby at some point.

Evidence of Ruby fame, or lack thereof:

http://www.rubygarden.org:3000/Ruby/page/show/RubyGolf/QuackingDuck :)
> -Toshio
>
> Fedora-infrastructure-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list

[David Douthitt]

Konstantin Ryabitsev wrote:
> I do hate cfengine (probably party due to the way it's set
> up here), and I do not consider puppet to be a good alternative,
> mostly because it's "yet another config language" and because it's
> written in ruby.

Well.... I personally think that puppet being written in Ruby is a 
plus :-P

However, puppet itself is not Ruby; it is only developed in Ruby. Ruby
is also used extensively for the FreeBSD portsupgrade tool and for 
Ruby on Rails. I suspect its more widely used than most realize, and 
if I'm not mistaken, Ruby is included in one or more of the standard 
Red Hat installs.

I must admit that the creation of my first customized Red Hat 
installation CDROMs was largely done to include Ruby v1.4....