Skip navigation.

Puppet dry run

Is the web site down?” asked my boss. Probably the five words I least want to hear, along with “I’ve run over your cat” and “I’ll pay you next month”.

Yes, the site was down - I’d made a minor Puppet change, and assumed this would roll out without any problems. Of course, the problem with assumptions is that they make an ASS out of U in front of your BOSS. Whenever I use Puppet to make changes to production servers, I like to do it by running Puppet manually, rather than waiting for the half-hourly auto-run, and I like to do a dry run first to see what’s going to happen.

Puppet’s dry-run feature is a powerful tool that’s often overlooked by busy sysadmins. Even if you test your Puppet manifests on a virtualised replica of your production site, which many people don’t have the time or the budget to do, pushing changes out live can have unforeseen side effects which are best avoided.

To dry-run Puppet, use the --noop flag:

# puppetd --test --noop
info: Caching catalog at /var/puppet/state/localconfig.yaml
notice: Starting catalog run
> This change will screw up your Apache server.
notice: //Node[soupnazi]/nagios::server/apache/File[/etc/httpd/conf/httpd.conf]/source: 
  is {md5}327dc6b2d2337e4467840c007a0edd61, should be puppet:///apache/httpd.conf (noop)
info: //Node[soupnazi]/nagios::server/apache/File[/etc/httpd/conf/httpd.conf]: Scheduling refresh 
  of Service[httpd]
notice: //Node[soupnazi]/nagios::server/apache/Service[httpd]: Would have triggered refresh from 1 
notice: Finished catalog run in 8.93 seconds

Puppet’s ‘noop’ (no-operation) mode shows you what would happen, but doesn’t actually do it. As you can see, Puppet reports that it would have updated the httpd.conf file and restarted Apache, and it helpfully shows us the line it would have inserted into the file:

> This change will screw up your Apache server.

Aren’t you glad you added the --noop flag? Of course, whenever you’re contemplating rolling out changes to a live server like this, you’ll want to stop the Puppet daemon running on the box temporarily (or disable the cron job if you run Puppet out of cron). The last thing you want is Puppet running automatically in “really do it” mode while you’re scrambling to fix the broken manifest.

Puppet’s dry run mode is not perfect - resource Y may fail because it requires resource X, for example, and resource X has not really been applied. Puppet isn’t so clever as to model the state of the box if each resource had been really applied - which is not surprising, because that’s a hard problem. Luckily, it doesn’t need to be perfect: dry-running Puppet in this way will catch a lot of small but potentially disastrous errors before they happen.

Opinions differ as to how meaningful or correct a dry-run mode can be, since changing the state of the box makes things unpredictable (Chef doesn’t have a dry run option at all), but I’ll take avoiding a disaster over academic arguments any day.

Thanks for getting the site back up,” said my boss. “Now, something else I meant to tell you. I’ll pay you next month.”

perfect configuration diff

Thanks for the article, John!

Just used `puppetd —test —noop` to ascertain my production “drift” from the github puppet repository. Now, I know exactly what I need to add/fix in puppet in order to get the live environment back in sync.

Re: perfect configuration diff


That’s a great point, and I hadn’t thought of using it that way. Good tip.

noop resources dependency

Hi John,

you mentioned briefly a situation when one resource depends on another and during noop mode this cause a problem. My question is simple: Is there a way how to tell puppet not to apply given resource during noop mode? I found noop metaparameter which does exactly the opposit - apply given resource even during noop mode (if I understand documentation correctly). Or to find a way to detect it from a manifest would also serve the purpose just wouldn’t so elegant and clean. The purpose is to avoid known or expected errors and do not disturb sys admins by expected errors.


Ways to get this reporting more meaningful?

Hi Folks,

Curious to know how do we set a reporting to know the future value of httpd.conf?
When run in noop mode, I understand it provides with a “+”, “-” sign about the change that it would do.
Also, without noop it does the changes and we see the previous value under “Events” in dashboard.
I’m trying to find a way to see the output of previous and current value as such. For easy comparison.
Could someone guide me on how to achieve this?
Moreover, When run in noop mode, if it tells the otuput as a file as such, it would be easy to identify the changes and communicate with people as necessary.

btw: Chef does have a dry-run-like feature

FYI: Chef’s feature that is like dry-run (—noop) is call “why-run” (-W or —why-run). I don’t know for sure if it was available in 2010 when this article was first written but I know it’s been there for at least the last 4 years that I’ve been using it.

It wasn’t! Thanks for

It wasn’t! Thanks for the update.

Post new comment

The content of this field is kept private and will not be shown publicly.
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Enter the characters shown in the image.
By submitting this form, you accept the Mollom privacy policy.