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,
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
On 02/01/07, David Lutterkort dlutter@redhat.com 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,
On 1/2/07, Konstantin Ryabitsev icon@fedoraproject.org wrote:
On 02/01/07, David Lutterkort dlutter@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.
-Mike
Mike McGrath wrote:
On 1/2/07, Konstantin Ryabitsev icon@fedoraproject.org wrote:
On 02/01/07, David Lutterkort dlutter@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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
On Tue, 2007-01-02 at 21:40 -0600, Mike McGrath wrote:
On 1/2/07, Konstantin Ryabitsev icon@fedoraproject.org wrote:
On 02/01/07, David Lutterkort dlutter@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.
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
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 Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
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....
infrastructure@lists.fedoraproject.org
-
David Douthitt -
David Lutterkort -
Konstantin Ryabitsev -
Michael DeHaan -
Mike McGrath -
Toshio Kuratomi