Robin Bowes

Volcane recently asked in ##infra-talk on Freenode if anyone knew of " some little tool that can be used in a cronjob for example to noop the the real task if say load avg is high or similar?" I came up with the idea to use nagios plugins. So, for example, to check load average before running a task: /usr/lib64/nagios/plugins/check_load -w 0.7,0.6,0.5 -c 0.9,0.8,0.7 >/dev/null && echo "Run the task here" Substitute the values used for the -w and -c args as appropriate, or use a different plugin for different conditions.

In a previous post , I described how to describe puppet environments, roles, and profiles, as modules and how to use r10k and librarian-puppet to deploy them. One possible problem with deploying to the puppet environment directory directly is that the librarian-puppet run can take some time and there is a possibility that puppet may attempt to compile a catalogue in an incomplete or inconsistent environment. One way to overcome this is to deploy the environments into a new directory, create a symlink, and move the symlink atomically into place . This would look something like this: cd /etc/puppet/envs# create a new dir under /etc/puppet/envs - I use a timestamp in the name so I know when it was createdNEW_ENV_DIR=$(mktemp --directory envs.$(date -Isec).XXX")cd /etc/puppet# use r10k deploy the environments into the new dirPUPPETFILE_DIR="envs/${NEW_ENV_DIR}" r10k puppetfile install# loop over all the environments and use librarian-puppet to deploy all the roles/pro...

By treating roles and profiles as puppet modules, we can use  r10k  and  librarian-puppet to manage the deployment of our puppet code into our puppet environements. I shall assume that puppet is configured to use to use directory environments and that the environment path is $confdir/environments (ie. the default location). I also assume that both r10k and librarian-puppet are installed and in the path. You should also understand and embrace the role-profile-module pattern, first described by Craig Dunn  and subsequently by Adrian Thebo  and Gary Larizza . Quoting Gary: Roles abstract profiles Profiles abstract component modules Hiera abstracts configuration data Component modules abstract resources Resources abstract the underlying OS implementation   I find the following points useful to clarify the purpose of each of the layers in this model: Roles, profiles, and component modules can all be implemented as...