Puppet users - Mar 2009 - I'm struggling with testing configuration changes locally - how to verify templates, syntax, results without checking in manifests

All manifests are in SCM. So far, I''ve checked in and ran puppetd --
test on a host machine to force an update. I look at how it fails, and
check in a correction. Repeat.

This isn''t a good way for me to make changes to systems. So, how can I
test a manifest change through the full stack of puppet on just one
node? This nodes is also under normal puppet control, but I am willing
to take it off for a while when I am testing.

I read some, but it seems like there are multiple ways and I never got
the right way yet.
 - http://reductivelabs.com/trac/puppet/wiki/TestingGuide


Can anyone point me to a simple way to force a local puppetmaster to
work against my current SVN working directory. And push the changes
locally to my puppetd running? So I can see if I will break things
without checking in?

Thanks!

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

On Mon, Mar 23, 2009 at 09:03:27PM -0700, jawspeak
wrote:
> 
> Can anyone point me to a simple way to force a local puppetmaster to
> work against my current SVN working directory. And push the changes
> locally to my puppetd running? So I can see if I will break things
> without checking in?
You could use environments for this.  Configure your puppetmaster so
that the paths for your testing environment point to your SVN checkout
and force the environment for the test.

http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments

-- 
Bruce

If the universe were simple enough to be understood, we would be too
simple to understand it.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi,

Here is the way summary of the way I work, don''t know if it will help.

I run a openvz virtualized infrastructure.
I use a external node script.
I use two enviroments production and testing. Both sets of manifests
are kept in subversion.

On the puppetmaster I check out the stable (this is production) tagged
version. (We are talking subversion tag here).
To /etc/puppet/ it contains the following directories that I''m
interested in

/etc/puppet/production contains a modules and a manifest directory

I then create /etc/puppet/testing which isn''t under version control. I
then check out trunk/production/manifests and modules
into the testing directory.

To test I create a new vz container of the server type I require and
depending upon how I name the node the external node script sets
the variable $puppetenv which contains either testing or production.

This then sets the environment in the puppet.conf template in the
puppet module for the newly created container.

When I''m happy with the changes I have made I then create a new
subversion tag and then update puppetmaster from subversion.

Don''t know how clear this is, if you have any questions I''ll
happily elaborate.

Martin



On Tue, Mar 24, 2009 at 6:36 AM, Bruce Richardson <itsbruce@workshy.org>
wrote:
>
> On Mon, Mar 23, 2009 at 09:03:27PM -0700, jawspeak wrote:
>>
>> Can anyone point me to a simple way to force a local puppetmaster to
>> work against my current SVN working directory. And push the changes
>> locally to my puppetd running? So I can see if I will break things
>> without checking in?
>
> You could use environments for this.  Configure your puppetmaster so
> that the paths for your testing environment point to your SVN checkout
> and force the environment for the test.
>
> http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments
>
> --
> Bruce
>
> If the universe were simple enough to be understood, we would be too
> simple to understand it.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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 everyone. Here''s my update, based on hacking around with:
http://reductivelabs.com/trac/puppet/wiki/TestingGuide

Scenario: my machine I want to test puppet on is also a puppet
controlled workstation. So common apache config settings, etc are
pushed to it. Thus I first stop puppetd. Then I install puppetmaster
with apt-get. I also have my subversion working directory set up as
where my new puppet server will look for changes.

I create a modified config in /etc/puppet/config-for-testing

I start puppetmaster with:
  sudo puppetmasterd --verbose --manifest /home/twdiamond/work/puppet-
repo/trunk/master/manifests/site.pp  --confdir /etc/puppet/config-for-
local-puppetmaster-testing/ --certname localhost

I tail syslog (very helpful for errors):
  tail -f /var/log/syslog

I start puppet with:
  sudo puppetd --verbose --confdir /etc/puppet/config-for-local-
puppetmaster-testing/ --server localhost --onetime --certname
localhost

When I run puppetd with those configs, it will push local changes
(including templating updates) to this machine, without checking
things into SVN and attempting to go out to all machines.

On Mar 24, 3:31 am, Martin Wheldon <mwhel...@googlemail.com>
wrote:
> Hi,
>
> Here is the way summary of the way I work, don''t know if it will
help.
>
> I run a openvz virtualized infrastructure.
> I use a external node script.
> I use two enviroments production and testing. Both sets of manifests
> are kept in subversion.
>
> On the puppetmaster I check out the stable (this is production) tagged
> version. (We are talking subversion tag here).
> To /etc/puppet/ it contains the following directories that I''m
interested in
>
> /etc/puppet/production contains a modules and a manifest directory
>
> I then create /etc/puppet/testing which isn''t under version
control. I
> then check out trunk/production/manifests and modules
> into the testing directory.
>
> To test I create a new vz container of the server type I require and
> depending upon how I name the node the external node script sets
> the variable $puppetenv which contains either testing or production.
>
> This then sets the environment in the puppet.conf template in the
> puppet module for the newly created container.
>
> When I''m happy with the changes I have made I then create a new
> subversion tag and then update puppetmaster from subversion.
>
> Don''t know how clear this is, if you have any questions
I''ll happily elaborate.
>
> Martin
>
> On Tue, Mar 24, 2009 at 6:36 AM, Bruce Richardson
<itsbr...@workshy.org> wrote:
>
> > On Mon, Mar 23, 2009 at 09:03:27PM -0700, jawspeak wrote:
>
> >> Can anyone point me to a simple way to force a local puppetmaster
to
> >> work against my current SVN working directory. And push the
changes
> >> locally to my puppetd running? So I can see if I will break things
> >> without checking in?
>
> > You could use environments for this.  Configure your puppetmaster so
> > that the paths for your testing environment point to your SVN checkout
> > and force the environment for the test.
>
> >http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments
>
> > --
> > Bruce
>
> > If the universe were simple enough to be understood, we would be too
> > simple to understand it.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---