ReleaseEngineering/PuppetAgain

History

Releng once used ReleaseEngineering/Puppet a puppet infrastructure based on Puppet-0.24.8, and manifests at http://hg.mozilla.org/build/puppet-manifests/. This had a few weaknesses:

• lots of assumptions and fragile dependencies based on bugs in 0.24.8
• very few modules - mostly manifest files, organized per slave type, rather than per service/purpose
• many references to external files which are not as available as the repo itself
• puppet manifests assume some manual ref-image steps; external exact reproduction is extremely difficult

Dustin started work on a new puppet deployment - chronicled at User:Djmitche/New Releng Puppet Infrastructure. That's this puppet.

System Description

Quick info:

• Manifest repository: http://hg.mozilla.org/build/puppet

Puppetmasters

Releng puppet masters are managed by IT (in fact, managed by IT's puppet infrastructure, which can lead to some confusion). There will be as many puppet masters as required, attempting to minimize the need communication across WAN links. The puppet masters do not permit root logins by non-sysadmins, but automatically update from the manifest repository using a crontask. As described below, masters also allow user logins for a limited set of people, who can set up puppet environments.

See ReleaseEngineering/PuppetAgain/Puppetmasters for more.

Puppet Versions

The releng puppet infrastructure will be using the same puppet versions as the rest of Mozilla. This generally tracks the latest puppet release. As IT upgrades, the masters will be upgraded; releng can then upgrade the clients using puppet itself.

Base Images

The base images for this infrastructure are barely-modified OS installs. They have just enough installed that they can connect to a puppet server, get certificates, and puppetize on boot.

See ReleaseEngineering/PuppetAgain/Base Images for more.

Manifests & Modules

The Puppet manifests themselves are documented here. Any new

Settings

The file manifests/settings.pp specifies a global settings for the puppet manifests. It specifies releng values for settings that other sites or users may want to change. This file is currently checked in and used as-is, but if it becomes necessary it can be changed to work like secrets.pp.in. The settings are:

• puppet_notif_email - email address to which errors in running puppet will be sent.

Secrets

The file manifests/secrets.pp.in specifies a template for per-site settings; this must be copied to manfiests/secrets.pp and filled in with appropriate secret values for the site. The current secrets are:

Modules

Masters are resolved by slaves with the unqualified hostname puppet.