best way to test snippets of puppet config

[russell.fulton]

Over the last few weeks I have several times felt the need to test out
some small snippets of puppet code without having to have them in my
live system.

At the moment I am doing all my testing by fiddling with file on the
puppet master and then invoking puppet on one of the clients. There
must be a better way :)

hmmm... setting up a node called 'test' and invoking puppetd --test --
fqdn test ???

I have also often wanted to "drop in some diagnostic writes" to find
out what the value of variables are without having to use erb and peer
at the generated files.

Anyone have tips on this stuff?

Thanks Russell

PS. yes, I know puppet is a configuration management system *not* a
programming language :)

[R.I.Pienaar]

hello,

----- Original Message -----
> Over the last few weeks I have several times felt the need to test out
> some small snippets of puppet code without having to have them in my
> live system.

I've blogged a number of techniques at http://www.devco.net/archives/2009/08/19/tips_and_tricks_for_puppet_debugging.php

[Craig Miskell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

russell.fulton wrote:
> Over the last few weeks I have several times felt the need to test out
> some small snippets of puppet code without having to have them in my
> live system.
>
> At the moment I am doing all my testing by fiddling with file on the
> puppet master and then invoking puppet on one of the clients. There
> must be a better way :)

I've got a test compile script which runs over all our hosts and ensures that
the manifests compile for each. I run this before committing to version control
(will eventually run this as a pre-commit hook). The command for a single host
looks something like:

/usr/sbin/puppetmasterd --vardir=./vartmp/ --confdir=. --ssldir=./vartmp/ssl
- --config=./puppet-testconfigs.conf --compile $hostname

Note that I have to have a local "vartmp" directory to be able to write to as a
non-root user. You can either check the output (redirect it?) or check the exit
code. If the latter is not 0, then the compile failed.

The good thing is, with this, you can run it as a non-root user (safe), and it's
not actually being applied anywhere (excellent if you make some mistakes).

- --
Craig Miskell
Senior Systems Administrator
Opus International Consultants
Phone: +64 4 471 7209
Computer games don't affect kids. I mean, if Pac Man had affected us as
kids, now we'd all be running around in darkened rooms, bumping into
people, munching pills and listening to repetitive electronic music.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkzrAJsACgkQmDveRtxWqnZmugCaAmR4egKZFfC5WqIQCi5hhjB5
eBkAnjSqQDnJYMztF6C/tOFkmCOS9Eeg
=q7OS
-----END PGP SIGNATURE-----

[donavan]

On Nov 22, 3:21 pm, "russell.fulton" <russell.ful...@gmail.com> wrote:
> Over the last few weeks I have several times felt the need to test out
> some small snippets of puppet code without having to have them in my
> live system.
>
> At the moment I am doing all my testing by fiddling with file on the
> puppet master and then invoking puppet on one of the clients. There
> must be a better way :)

I suggest taking a look at 'cucumber-puppet'[1]. I'm primarily using
it to test catalog compilation, but you can inspect individual
resources as well.
RI also has some great tools to testing and comparing[2] catalogs. You
can compare changes before you actually apply to 'new' catalog to the
clients.

[1] http://projects.puppetlabs.com/projects/cucumber-puppet
[2] https://github.com/ripienaar/puppet-catalog-diff

[Nigel Kersten]

On Tue, Nov 23, 2010 at 12:26 AM, donavan <don...@desinc.net> wrote:
> On Nov 22, 3:21 pm, "russell.fulton" <russell.ful...@gmail.com> wrote:
>> Over the last few weeks I have several times felt the need to test out
>> some small snippets of puppet code without having to have them in my
>> live system.
>>
>> At the moment I am doing all my testing by fiddling with file on the
>> puppet master and then invoking puppet on one of the clients. There
>> must be a better way :)
>
> I suggest taking a look at 'cucumber-puppet'[1]. I'm primarily using
> it to test catalog compilation, but you can inspect individual
> resources as well.
> RI also has some great tools to testing and comparing[2] catalogs. You
> can compare changes before you actually apply to 'new' catalog to the
> clients.

I've always found it immensely useful to just use standalone puppet
manifests (in modules or otherwise) with the ability to set variables
by using FACTER_* environment variables.

FACTER_somevariable="somevalue" puppet apply -v /tmp/test.pp

You can get an awful lot of testing done really quickly like this.
FACTER_somevariable gets exposed as $somevariable in the manifests.

I'm pretty sure RI has covered this in his posts, but it's how I
generally do the first stage of testing, the "does this actually work
like this?" stage.