Testing Puppet Code

Nowadays I find myself working with Puppet.
One of the biggest challenges I’ve found with working with Puppet is that the nature of the Puppet language is very different than your standard programming languages like Ruby, Python or even C/C++. First off, Puppet is a declarative language. So in Puppet the flow of control of your script is not determined by the order of your code. For example:

Here is some puppet code to create two files on a system.

file{ "/tmp/file1.txt":
    content => "this is the text in file1",

file{ "/tmp/file2.txt":
    content => "this is the text in file2",

In the code above the file1 is not guaranteed to be created before file2 is created. In order to create file1 before file2, you have explicitly indicate it in your code.

In order to ensure file1 is created before file2 is created, this is what you have to do:

file{ "/tmp/file1.txt":
    content => "this is the text in file1",

file{ "/tmp/file2.txt":
    content => "this is the text in file2",
    require => File["/tmp/file1.txt"],

As you can imagine the dependencies between systems resources can get pretty harry so you really need to think about how to organize your code. However, if you split up your Puppet script into high level components managing the dependencies is not so bad. Here is a good example of how to do that: simple module structure

The more challenging part about working with Puppet is testing your code. There doesn’t seem to be any testing support built into Puppet, and I haven’t found any test utilities or strategies. I think this is an area the guys at PuppetLabs should really work on.

Yet I still need to test my code, so the approach I have decided to take to test code is to do a dry run. Puppet has a “–noop” parameter that essentially runs your puppet code without applying any changes to the system. This will give some indication if your code will run successfully. However, it is not full proof. You can still run into system level problems when you actually run your code.

Ideally you should have a test environment where you can do actual puppet runs of your modules. Each module should and an install and remove script defined. Then your test run commands could look something like this:

puppet --noop /etc/puppet/modules/apache/tests/test_install.pp
puppet --noop /etc/puppet/modules/apache/tests/test_remove.pp

However, the problem here is if your modules contain errors and don’t run properly you could leave the system in an unknown state, making your next test run invalid.

For now I’ll settle for simply doing dry runs, but hope to find a better solution soon.

Tagged with: ,
Posted in puppet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: