Puppet apply and the puppet master need to start somewhere when compiling a puppet catalog.

When control repo is used by the puppet master, the manifests/ directory is this start;  or entry point.

Puppet apply needs to be told what to run; point it at a directory with puppet manifests in them, and it’ll process them all.

Puppet supplies site.pp in their control repo to be the start point of the compilation for the Master. If puppet apply is pointed at that directory, and nothing else is in there, it’ll apply control repo in a manner comparable to a puppet master.

Try puppet apply

Now you can try puppet apply! I’m assuming your git repository is still in the state it was at the end of the previous post.

$ git status
# On branch puppetapply01
nothing to commit, working directory clean

The code puppet will run is in:

manifests/site.pp
# or 
/etc/puppetlabs/code/environments/local/manifests/site.pp

The file has a lot of comments in it, but the active ingredient is:

node default {
  notify { 'hello world':
    withpath => false,
    loglevel => 'verbose',
  }
}

So, here’s our first call out to puppet apply using our control repo

sudo /opt/puppetlabs/bin/puppet apply --test --environment=local /etc/puppetlabs/code/environments/local/manifests

And the business end of the output will be:

Info: hello world
Info: /Stage[main]/Main/Node[default]/Notify[hello world]/message: defined 'message' as 'hello world'
Notice: Applied catalog in 0.85 seconds

–test

The ‘test’ command line switch for puppet is generally used for interactive use.

puppet help apply
<snip>
* --test:
Enable the most common options used for testing. These are 'verbose',
'detailed-exitcodes' and 'show_diff'.
<snip>

Shorter version

All that is a bit tedious to type, so there’s a script for that too.

sudo /etc/puppetlabs/code/environments/local/scripts/puppetapply.sh

I continue to assume you’re working directory is the root of the control-repo, so try:

sudo scripts/puppetapply.sh

It prints out the puppet apply command just before running it, so if an error is generated, you can see what it was trying to do.  It always passes –test.

–noop

The script is coded to pass in one optional parameter; I often use ‘–noop’ with puppet apply and puppet agent so you can, for example:

sudo scripts/puppetapply.sh --noop

noop does this:

puppet help apply
<snip>
* --noop:
  Use 'noop' mode where Puppet runs in a no-op or dry-run mode. This
  is useful for seeing what changes Puppet will make without actually
  executing the changes.
<snip>

It’s a good idea to do a noop run before applying the changes.

• When developing (and learning) you can check the code is about to do what you expected.
• If the code is going to fail to run, you often get that in noop mode; you can fix it, and try again. Repeat until it runs clean, and then check it does what you expected!
• If you’re applying changes in anger in production, you want to do a noop run first to protect yourself. Experience reading noop output is therefore useful.

For most/all of the posts, I will comment out –noop each time puppetapply.sh is called, as a reminder to consider a dry run to see what’s about to happen.

making changes

As a rule, if you add or change anything, git will make you do something about it before you can check out another branch.

This will be my only git guidance, as it’ll make it difficult to experiment without making changes. I want to do better than: https://xkcd.com/1597/

My suggested approach is to append your changes to the branch before moving on. You’ll still be able to refer back to those changes by checking out the branch within your local copy of the repository, or if you don’t want to keep them, delete the branch.

A worked example:

$ git status
# On branch puppetapply01
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: manifests/site.pp
#
no changes added to commit (use "git add" and/or "git commit -a")

$ git diff
[..]
   notify { 'hello world':
-    withpath => false,
+    withpath => true,
     loglevel => 'verbose',

$ git add manifests/site.pp
$ git status
# On branch puppetapply01
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: manifests/site.pp
#

$ git commit -m 'playing around with site.pp'

• It will more than likely then tell you to sort out your name and email address.
• If you’ve made multiple changes, you’ll get two lists – ‘Changes to be committed’, and ‘Changes not staged for commit’ until you add them all.
• If you add a file, and then change a second time, it’ll appear twice in the output, as you’ve added one change, and then made another. This is one area that folk find git unintuitive.
• Once you’ve checked out another branch, you can delete the one you’ve changed and then you can check the original one out again.

git branch
git checkout anotherbranch
git branch -d puppetapplyxx
 # note the warning, which is that you have local changes, then:
git branch -D puppetapplyxx

Next

puppet apply #4 – a profile