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.
_______________________________________________
Labs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/labs-l
