Promote puppet to main?

[John Moser]

Are there any specific reasons for not promoting Puppet and/or Chef to 
main in the next release or two?  I'm leaning on Puppet because that's 
what I'm using, because it's easier to learn somehow (more books about 
it, better documentation, and just falls together); Chef, Ansible, and 
cfengine are fairly popular as well.

These tools centralize configuration.  Puppet is declarative (you tell 
it what you want the system to look like) and idempotent (you WILL get 
the same results no matter what order things are executed in, no matter 
how many times you execute them); Chef is imperative (you tell it how to 
do it); the others are unknown to me.

In Puppet specifically, a pile of stuff goes into the modules describing 
what the system should look like and which bits depend on which other 
bits.  The modules specify packages to install, configuration files 
(from files or from templates modified by parameters), services that 
must be running, and relationships (dependencies, alerts i.e. for the 
purpose of restarting services when a configuration file is changed, 
etc).  Classes in the modules may take parameters, allowing for 
interesting configuration--a Web server node could include 
nodes/web-01.example.com/vhosts/*, which are a bunch of .pp files 
importing the apache::config::vhost class with different parameters, 
thus generating a bunch of files for the vhosts configured on the server.

This allows you to stand up a system instantly by pointing the Puppet 
agent at Puppetmaster.  All required packages are installed, 
configuration files are brought in, and services are started. Modifying 
any configuration files on the Puppetmaster server will produce updates 
on the given node; these updates may cause services to restart, if 
necessary.

Puppet examines the remote system and makes decisions about what kind of 
configuration it needs.  It can decide if apt-get, emerge, yum, pkginst, 
or the like is needed to install a package.  It will inform the modules 
of many OS parameters including type, version, processor type, and other 
things, so that decisions can be made--for example, to use a RedHat 
specific config file, or to use a different package name on Solaris than 
on Ubuntu, or to generate the /etc/apt/sources.list.d/ files with 
'debian' or 'ubuntu' and with 'squeeze' or 'edgy' or 'precise'.


A TLS certificate is generated, signed by the puppet server, and placed 
on the remote server; the common name in the certificate is used as the 
node name.  Puppet can automatically generate a signed certificate for a 
new node, using its hostname as a common name, and push it to the 
agent.  It is preferable to manually generate the certificate in 
high-security settings.  Puppet has an access control list based on 
whether an agent is "authenticated" (i.e. presents a signed, known 
certificate) or not, which provides four of the primary security 
guarantees (Authentication, Authorization, Confidentiality, Integrity).


You can also create a subversion repository for /etc/puppet/modules and 
/etc/puppet/manifests.  Check out your modules or your manifests, make 
changes, then check them in and have subversion respond to a check-in by 
pushing an update to the Puppet server. Chef allows you to store 
Cookbooks in a git repository, so you can always roll back to a previous 
Cookbook version and apply different versions of Cookbooks to different 
servers.

Bringing Puppet into main and giving puppet and puppetmaster their own 
Tasksel entries in Ubuntu Server would represent a significant step 
forward.  Chef is more of an unknown to me, as I had difficulty getting 
started with it; I know of a few places that do use Chef and, as well, 
Ansible and cfengine, so there is market for all such tools.  Puppet 
seems to have the greatest mind share at the moment; and of course, 
obviously, as stated, I have my own preference for it at the moment.

There are also excellent books on Puppet such as Pro Puppet by John 
Turnbull.

And whatnot.

Did anybody actually not know what these things are?