This module handles installing, updating, and running puppet.
The puppet class is imported in toplevel::base, and takes care of installing and configuring puppet. Releng uses two modes of puppet startup, so there are two classes that must *also* be included to make sure puppet actually runs.
How puppet clients use puppet masters
There are some ways to specify which puppet master clients should talk to:
- Single puppet master. Used by puppet::periodic (usually for masters). Random puppet master can be choosen by setting puppet_server CSV variable (usually in manifests/extlookup/local-config.csv) to <<RANDOM>>.
- Multiple puppet masters. Used by puppet::atboot (usually for slaves). If puppet_server CSV variable set to <<RANDOM>>, then /etc/puppet/puppetmasters.txt file will be populated with a shuffled list of puppet_servers (from CSV files). Otherwise, puppet_server will be the top entry in /etc/puppet/puppetmasters.txt; other puppet masters from puppet_servers will be appended in random order.
- No masters (standalone). Used by puppetmaster::standalone. A cronjob runs "puppet apply" if there are changes in the puppetagain repo to keep the master up to date.
If /etc/puppet/standalone file exists it runs puppet in "apply" (standalone) mode by running /etc/puppet/update.sh. Otherwise this runs puppet the "normal" way - puppet consults the puppetmaster every 30m or so. It is used for any subclass of toplevel::server.
At the moment "standalone" method is iused by toplevel::server::puppetmaster::standalone.
This runs puppet at boot. It is used for any subclass of toplevel::slave. On Linux, the startup process blocks until puppet has run successfully, and reboots after a number of unsuccessful runs. On OS X, launchd does not allow one process to block another, so the puppet process runs puppet (as root) repeatedly until it is successful, and then touches a sentinel file that indicates to the buildslave process that it is safe to start. See ReleaseEngineering/Buildslave Startup Process for more details.