[Labs-l] Puppet docs

[Marc A. Pelletier]

On 03/12/2013 07:17 AM, Dan Michael O. Heggø wrote:
> Perhaps puppet is not supposed to be used by the average tool
> maintainer, but it would be nice to clarify, as you say, when it makes
> sense to puppetize and not, and what is considered "best practice" for
> deploying a tool with some dependencies.

The nutshell:  puppet is a system by which you describe the 
configuration of a machine.  When used, it will apply the necessary 
changes to make the machine you apply it to match that configuration.

In practice, the sysadmin would make any change of configuration 
intended for the machine in puppet (including what to install, files to 
edit, etc) so that it can be reapplied to a blank machine to configure 
it "just like it was", or to make a clone, and so on.  In the case of a 
project where the tool maintainer do the system administration, it might 
be desirable to acually configure and install the tool /itself/ through 
puppet so that it is easy to return to a known state.

In the case of the Tool Labs, however, the actual tools would not 
normally be configured through puppet*:  they live on a shared 
filesystem rather than on the individual machines.  What puppet /is/ 
used for is to maintain the components of the grid, making adding "one 
more compute node" or "an extra webserver" as simple as to create a new 
instance and set puppet accordingly.  When we find a tool has a 
dependency, the tools labs sysadmins will add it to puppet so that every 
host part of the grid (current and future) will have that configured 
accordingly without manual intervention.

-- Marc

* It remains /possible/ to do so, but almost certainly not worthwhile.  
I'll make a note to explain that in more detail in the docs.