Puppet users - Jun 2009 - Testing manifests before you check in?

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
http://www.build-doctor.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Julian Simpson schrieb:
> 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?
[good ideas for local testing]
> 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.
One of my problems with this approach is my heavy usage of 
export/collect. A significant portion of my problems only surface after 
more than one node has exported resources AND another one has collected 
them. For me that means that a serious setup will have to have a live 
testing environment that has instances of all live services and 
integrates all recent changes from the developers. Changes that have 
survived a few days without killing the testing environment then can be 
rolled out into production.


For my personal systems I just develop in the "development"
environment
and manually test on the live servers with "puppetd --test 
--environment=development --noop" until I''m satisfied. Which, I
have to
admit is not very rigorous. But then, I''m a one-man, few-nodes outfit 
and can cut corners, others can''t cut.



Regards, DavidS

-- 
dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
Klosterneuburg                                         UID: ATU64260999

        FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Thanks for sharing, David.  Maybe there''s the rub.  The big systems
can''t be reduced down to such a simple approach, and the little
systems don''t require such rigour?  I don''t run many nodes but
I do
have this obsessing with testing infrastructure.

J.
> One of my problems with this approach is my heavy usage of
> export/collect. A significant portion of my problems only surface after
> more than one node has exported resources AND another one has collected
> them. For me that means that a serious setup will have to have a live
> testing environment that has instances of all live services and
> integrates all recent changes from the developers. Changes that have
> survived a few days without killing the testing environment then can be
> rolled out into production.
>
>
> For my personal systems I just develop in the "development"
environment
> and manually test on the live servers with "puppetd --test
> --environment=development --noop" until I''m satisfied. Which,
I have to
> admit is not very rigorous. But then, I''m a one-man, few-nodes
outfit
> and can cut corners, others can''t cut.
>
>
>
> Regards, DavidS
>
> --
> dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
> Klosterneuburg                                         UID: ATU64260999
>
>        FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg
>
> >
>


-- 
Julian Simpson
Software Build and Deployment
http://www.build-doctor.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---