Since introductions are all the vogue today, here's some background about me: I work in Red Hat's Emerging Technologies group on systems management things; a little over a year ago I got interested in configuration management and started looking around for a tool that could fill the gaps left by the current tool chain that people use (well, a very short chain generally, mostly made up of package management and a little bit of source control)

During that time, I looked at pretty much all the config mgmt tools out there, and found that puppet has the most promise of the lot, both for straightup config mgmt and for pushing the envelope of what can be done there (e.g., distributing detailed configurations in a reusable way[1]) Before that, I worked on RHN for a while, and before that I did a lot of consulting work for Red Hat, mostly around J2EE web applications. I used to know TCL, but the rehab really helped.

In the interest of full disclosure, I actively contribute to puppet and work on stuff building on it.

I will be out of town until Jan. 2nd, with unclear email access, so I might be a little sluggish with responses - but you can always ask questions on puppet-dev@reductivelabs.com or #puppet on freenode.

Puppet ======

The references like [N] are at the end and lead to docs/additonal info

PROS ---- * Project lead (Luke Kanies) is experienced as sysadmin and consultant around system administratio, makes his living exclusively off consulting around puppet * Designed and implemented in direct response to experiences with other (and no) config mgmt systems like cfengine [5], isconf, sth proprietary etc. * Architecture * Clients connect to central server (but all sane cfg mgmt tools do that) * Clients report facts about themselves (OS/kernel version/release, MAC/IP address, basic HW info) to central server, which uses them to make decisions about client's config; the fact mechanism is pluggable and can be easily extended with custom facts * Server assembles config for client from sitewide description (manifest) * Can also be used standalone with cmd line tool for testing (or dirt simple single machine setups) * Use 'native' tools for all config tasks in the backend (e.g., yum for pkg mgmt on RH-derived systems) * Security * Thorough security model (each client has its own SSL cert) Puppet comes with tools to make basic SSL setup and cert generation very painless (puppetca) * Each client only gets to see the part of the site config that applies to it, not the whole site config * Builtin file server where file access can be secured per-client (e.g. only hostX gets access to hostX/ssh_host_key) * Cross-platform, works on most flavors of Unix (Fedora/RHEL/Debian/Gentoo, Solaris, OS X, some sort of *BSD IIRC) * Domain-specific language for manifest [2] * Clean abstraction from messy details of changing config * Describe desired config of system, puppet figures out how to get there (e.g., you say 'need user X with homedir /foo and uid N', puppet figures out appropriate calls to useradd/usermod depending on whether user exists and fixes attributes that are out of sync) * Abstraction: describe config in high-level terms (user, service, package, mount) for common config objects [3] * Templating support for things that can't/don't need to be described as objects; or distribute complete files * Group config items logically with classes: can describe that a webserver has to have latest httpd package, service httpd enabled and running, and custom httpd.conf file from location X (that's not possible with at least one of the other config mgmt tools) * Override mechanism for classes to allow for simple one-off (or hundred-off) tweaks, e.g. to take webserver class from above but use with different httpd.conf * Clean definition of what inputs can influence a client's config * Language makes config easily readable and comprehensible IMHO * Emphasis on practical usability, not research * Good set of unit tests * No EditFiles ;) * Cron-like support for scheduling actions during maintenance windows (on a per-config object basis, if need be, though in reality you want to keep that simple for your own sanity) * Tie-in with kickstart: provision basic system with ks (including puppet client), complete config with puppet [4] * RH interested in furthering it for other reasons, too * Active community, Luke is very responsive both with developer and user issues/questions * Beginnings of task-oriented user docs on a Wiki [6] * GPL

CONS ---- * Not everybody is familiar with puppet's implementation language (Ruby) * Evolves rapidly * Some of the more esoteric features (like comprehensive reporting) are immature * Need to learn puppet's language to describe site config * Scalability in very large deployments unknown (there are production deployments in the low hundreds of machines) * Language is mostly declarative, but has 'exec' loophole for running arbitrary commands on the client for practical reasons

More info --------- Puppet's website (http://reductivelabs.com/projects/puppet/) has lots of more info; if you want to get more of an impression, I would start with the following, in this order: 1. http://reductivelabs.com/projects/puppet/faq.html 2. Luke's BayLISA presentation from last year (http://video.google.co.uk/videosearch?q=Kanies+puppet) - the ones from August '06 are also very good but _long_ 3. The high-level introduction (http://reductivelabs.com/projects/puppet/documentation/introduction.html) 4. Luke's puppet/cfengine comparison (http://reductivelabs.com/projects/puppet/documentation/notcfengine.html) and his blog post about BCFG2 (http://www.madstop.com/articles/2006/08/08/puppet-vs-bcfg2) - gives some more insight into the why's and how's of puppet and how the main author contrasts it with what's out there. 5. The language tutorial http://reductivelabs.com/projects/puppet/documentation/languagetutorial.html

David

[1] http://people.redhat.com/dlutter/puppet-app.html [2] http://reductivelabs.com/projects/puppet/documentation/languagetutorial.html [3] http://reductivelabs.com/projects/puppet/documentation/typedocs.html [4] http://watzmann.net/blog/index.php/2006/12/05/kickstarting_into_puppet [5] http://reductivelabs.com/projects/puppet/documentation/notcfengine.html [6] http://reductivelabs.com/cookbook/