puppet overview - pros and cons

[David Lutterkort]

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(a)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/