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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
