Adding classes

At present, puppet apply should look something like this:

$ sudo scripts/puppetapply.sh 
+ /opt/puppetlabs/bin/puppet apply --test --environment=local /etc/puppetlabs/code/environments/local/manifests
Info: Loading facts
Notice: Compiled catalog for clientname in environment local in 0.16 seconds
Info: Applying configuration version 'xxx'
Notice: Applied catalog in 0.09 seconds

Let’s add back in the clientscope class. This will populate an additional layer in hiera – if you’ve already looked at hiera.yaml, you’ll see that this filename is referred to.

$ cat data/role/role\:\:test1.yaml > data/puppetapply.yaml
$ cat data/puppetapply.yaml
---
classes:
- '::profile::puppet::clientscope'

You should then see the scope output file updated.

$ sudo scripts/puppetapply.sh #--noop
[..]
Notice: /Stage[main]/Profile::Puppet::Clientscope/File[/opt/puppetlabs/puppet/cache/site_agent_variables.yaml]/content: content changed

Run ‘git status’.  It’ll tell you the working directory is clean, even though you’ve created a file within control-repo;  this is because of .gitignore:

$ git status
# On branch puppetapply05
nothing to commit, working directory clean
$ grep puppetapply .gitignore 
data/puppetapply.yaml

Now there’s a way to add classes in, on the fly, when running puppet apply.

Driving logic with data

The next step is to push other sorts of data into control repo.

At present, common.yaml directs the motd code not to do anything.

$ grep motd_behav data/common.yaml 
profile::motd::params::motd_behav: 'ignore'

If you remove the motd files, they won’t be recreated.

$ sudo rm -rf /etc/motd /etc/motd_local
$ sudo scripts/puppetapply.sh #--noop

If you look at hiera.yaml ..

$ cat hiera.yaml 
---
version: 5

defaults:
datadir: "data"

hierarchy:
- name: 'Yaml backend'
data_hash: yaml_data
paths:
- 'puppetapply.yaml'
- "nodes/%{facts.hostname}.yaml"
- "role/%{facts.role}.yaml"
- 'common.yaml'

puppetapply.yaml is at the top of the list, and can mask anything below it, including common.yaml.

The following adds the motd_behav key to the file, having re-written it from ‘ignore’ to ‘deploy.

grep motd_behav data/common.yaml | sed 's~ignore~deploy~g' >> data/puppetapply.yaml

puppetapply.yaml should now look like this:

$ cat data/puppetapply.yaml
---
classes:
  - '::profile::puppet::clientscope'
profile::motd::params::motd_behav: 'deploy'

Try it ..

sudo scripts/puppetapply.sh #--noop

It should recreate the motd file, and the local fragment:

Notice: /Stage[main]/Profile::Motd::Local/File[/etc/motd_local]/ensure: created
Notice: /Stage[main]/Profile::Motd::Init/Concat[/etc/motd]/File[/etc/motd]/ensure: defined content as [..]

Conclusion

This control repo now provides a way to enable profiles within puppet apply on a machine, also to inject data into any profile, over-riding the rest of the hierarchy.

You can write a profile, pop it into the list in puppetapply.yaml, get it working, then push the changes to your git server.

puppetapply.yaml will never get flagged as having been created or changed; and if it’s missing (say, on a puppet master) hiera won’t care.

The hostname is one of the layers in the hierarchy.  So, without going further, we can distinguish data values used by default (common.yaml) and hostname, which is obviously a fact that comes into puppet from ‘outside’.

If you need to troubleshoot why data/nodes/hostname.yaml isn’t working, its probably because the fact doesn’t contain the string you expect – check the scope dump.

Next

puppet apply #9 – classification along side puppet apply