As you have already witnessed, the output presented by Puppet is rather verbose. As you get more experienced with the tool, you will quickly learn to spot the crucial pieces of information. Let's first take a look at the informational messages though. Apply the service.pp manifest once more:
root@puppetmaster:~# puppet apply puppet_service.pp Notice: Compiled catalog for puppetmaster.example.net in environment production in 0.48 seconds Notice: Applied catalog in 0.05 seconds
Puppet took no particular action. You only get two timings: one, from the compiling phase of the manifest, and the other, from the catalog application phase. The catalog is a comprehensive representation of a compiled manifest. Puppet bases all its efforts concerning the evaluation and syncing of resources on the content of its current catalog.
Now, to quickly force Puppet to show you some more interesting output, pass it a one-line manifest directly from the shell. Regular users of Ruby or Perl will recognize the call syntax:
# puppet apply -e'service { "puppet": enable => true, }' Notice: Compiled catalog for puppetmaster.example.net in environment production in 0.62 seconds Notice: /Stage[main]/Main/Service[puppet]/enable: enable changed 'false' to 'true' Notice: Applied catalog in 0.12 seconds.
Note
We prefer double quotes in manifests that get passed as command-line arguments, because on the shell, the manifest should be enclosed in single quotes as a whole.
You instructed Puppet to perform yet another change on the Puppet service. The output reflects the exact change that was performed. Let's analyze this log message:
The
Notice:keyword at the beginning of the line represents the log level. Other levels includeWarning,Error, andDebug.The property that changed is referenced with a whole path, starting with
Stage[main]. Stages are beyond the scope of this book, so you will always just see the default ofmainhere.The next path element is
Main, which is another default. It denotes the class in which the resource was declared. You will learn about classes in Chapter 4, Modularizing Manifests with Classes and Defined Types.Next, is the resource. You already learned that
Service[puppet]is its unique reference.Finally,
enableis the name of the property in question. When several properties are out of sync, there will usually be one line of output for each property that gets synchronized.The rest of the log line indicates the type of change that Puppet saw fit to apply. The wording depends on the nature of the property. It can be as simple as
created, for a resource that is newly added to the managed system, or a short phrase such aschanged false to true.
Another useful command-line switch for puppet apply is the --noop option. It instructs Puppet to refrain from taking any action on unsynced resources. Instead, you only get a log output that indicates what will change without the switch. This is useful in determining whether a manifest would possibly break anything on your system:
root@puppetmaster:~# puppet apply puppet_service.pp --noop Notice: Compiled catalog for puppetmaster.example.net in environment production in 0.63 seconds Notice: /Stage[main]/Main/Service[puppet]/enable: current_value true, should be false (noop) Notice: Class[Main]: Would have triggered 'refresh' from 1 events Notice: Stage[main]: Would have triggered 'refresh' from 1 events Notice: Applied catalog in 0.06 seconds
Note that the output format is the same as before, with a (noop) marker trailing the notice about the sync action. This log can be considered a preview of what will happen when the manifest is applied without the --noop switch.
The additional notices about triggered refreshes will be described later and can be ignored for the moment. You will have a better understanding of their significance after finishing this chapter and Chapter 4, Modularizing Manifests with Classes and Defined Types.