[Puppet Users] Testing manifests before you check in?

Julian Simpson
2009-06-14T10:57:24Z

I''ve seen some excellent discussion on how some people in the
community test their puppet manifests before they check in.  I''m still
left wanting a little more.  Perhaps I''m being a little pedantic?

What I  start with is making sure all the files are legal, with this Rake task:

  desc "Test"
  task :test do
        sh "puppet --parseonly  --modulepath=#{puppet_dir}/modules
#{site_manifest}"
  end

That catches the accidental syntax errors.  Of course, that''s no
guarantee that they will actually work in the slightest.  So what I
had been doing after that was to execute the manifests as a
non-priveleged user (typically when I''m on the train with my MacBook,
totally unable apply changes to Debian-esque systems anyhow):

  desc "Local Puppet Run"
  task :local do

    sh "puppet --debug --verbose --noop --environment=development
#{site_manifest} \
      --templatedir=#{puppet_dir}/templates \
      --modulepath=#{puppet_dir}/modules"
  end

This kinda works.  I''d get better mileage by developing in a VM on my
MacBook.  But it''s still not enough to tell that my manifests are
vaguely sane:  they depend on the fileserver to resolve mounts and the
puppetmaster to compile templates.  I started experimenting with
trying to make relative paths in the manifests and file:// urls, but
that got painful quickly.  What''s been most useful so far is running
''puppetd --test'' from the Rakefile.  That task depends on
another task
which invokes rsync to make sure that the ''/etc/puppet'' dir is
up-to-date.  Once we''re in production I won''t be doing that on
the
main puppetmaster machine.

So ideally, I''d like to be able to stand up a minimal version of the
puppetmaster (with some strings cut?)  for the duration of the test
run.  That would allow things like file serving without the SSL,
resolution of mounts, compilation of templates, etc.  Then at the end
of my invocation of ''rake puppet:my_great_test'', the
puppetmaster (
perhaps using --no-daemonize) would quit, and I could parse the puppet
output for errors.

The benefit for me is that you can test a lot and gain a good opinion
of things before you go to the next stage of deploying.  I''d like to
add this to my Continuous Integration service so a given version of my
infrastructure won''t get tagged unless it can pass this test.

Does this appeal to anybody else?  I''m keen to make sure that I
don''t
reinvent the wheel, or scratch an itch that nobody else feels.

Best,

Julian.

--
Julian Simpson
Software Build and Deployment