I''m worried about making bad changes to a module which will impact lots of hosts. How can I avoid this? Ideally I''d like every node to run in noop, and then to approve the changes if they look right. 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 Thu, Feb 23, 2012 at 11:09 PM, jimbob palmer <jimbobpalmer@gmail.com>wrote:> I''m worried about making bad changes to a module which will impact > lots of hosts. > > How can I avoid this? > > Ideally I''d like every node to run in noop, and then to approve the > changes if they look right. >Hi Jim, We''re not currently using this method, but we''re planning on using a second Puppet server which will have a copy of the Puppet tree with whatever major changes have been made in development. We run Puppet from cron so every host would continue to point at the master server, but we would connect to specific hosts and try noop against the second Puppet server. I''d like to hear how other people manage this sort of thing. - Gonzalo -- 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, On 02/23/2012 01:27 PM, Gonzalo Servat wrote:> On Thu, Feb 23, 2012 at 11:09 PM, jimbob palmer <jimbobpalmer@gmail.com > <mailto:jimbobpalmer@gmail.com>> wrote: > > I''m worried about making bad changes to a module which will impact > lots of hosts. > > How can I avoid this? > > Ideally I''d like every node to run in noop, and then to approve the > changes if they look right. > > > Hi Jim, > > We''re not currently using this method, but we''re planning on using a > second Puppet server which will have a copy of the Puppet tree with > whatever major changes have been made in development. We run Puppet from > cron so every host would continue to point at the master server, but we > would connect to specific hosts and try noop against the second Puppet > server. > > I''d like to hear how other people manage this sort of thing.similarly but using environments: http://docs.puppetlabs.com/guides/environment.html The nodes are made to do the noop run on their own and store their reports on the master. A simple script digests the reports. Cheers, Felix -- 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.
We have a stable environment and an evironment for every developer. Upon changes we manually test the change using the different environments. We also have alerting on the /var/lib/puppet/state/ last_run_summary.yaml file, which tells us if a manifest did not apply properly. Cheers, Jos On Feb 23, 2:13 pm, Felix Frank <felix.fr...@alumni.tu-berlin.de> wrote:> Hi, > > On 02/23/2012 01:27 PM, Gonzalo Servat wrote: > > > > > > > > > > > On Thu, Feb 23, 2012 at 11:09 PM, jimbob palmer <jimbobpal...@gmail.com > > <mailto:jimbobpal...@gmail.com>> wrote: > > > I''m worried about making bad changes to a module which will impact > > lots of hosts. > > > How can I avoid this? > > > Ideally I''d like every node to run in noop, and then to approve the > > changes if they look right. > > > Hi Jim, > > > We''re not currently using this method, but we''re planning on using a > > second Puppet server which will have a copy of the Puppet tree with > > whatever major changes have been made in development. We run Puppet from > > cron so every host would continue to point at the master server, but we > > would connect to specific hosts and try noop against the second Puppet > > server. > > > I''d like to hear how other people manage this sort of thing. > > similarly but using environments:http://docs.puppetlabs.com/guides/environment.html > > The nodes are made to do the noop run on their own and store their > reports on the master. A simple script digests the reports. > > Cheers, > Felix-- 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.
To avoid these problems, you can use Puppet’s dry run mode (also called noop mode, for ‘no operation’ puppet agent --test --noop 在 2012年2月24日 下午11:15，Jos Houtman <jos@hyves.nl>写道：> We have a stable environment and an evironment for every developer. > Upon changes we manually test the change using the different > environments. > > We also have alerting on the /var/lib/puppet/state/ > last_run_summary.yaml file, which tells us if a manifest did not apply > properly. > > Cheers, > > Jos > > > On Feb 23, 2:13 pm, Felix Frank <felix.fr...@alumni.tu-berlin.de> > wrote: > > Hi, > > > > On 02/23/2012 01:27 PM, Gonzalo Servat wrote: > > > > > > > > > > > > > > > > > > > > > On Thu, Feb 23, 2012 at 11:09 PM, jimbob palmer < > jimbobpal...@gmail.com > > > <mailto:jimbobpal...@gmail.com>> wrote: > > > > > I''m worried about making bad changes to a module which will impact > > > lots of hosts. > > > > > How can I avoid this? > > > > > Ideally I''d like every node to run in noop, and then to approve the > > > changes if they look right. > > > > > Hi Jim, > > > > > We''re not currently using this method, but we''re planning on using a > > > second Puppet server which will have a copy of the Puppet tree with > > > whatever major changes have been made in development. We run Puppet > from > > > cron so every host would continue to point at the master server, but we > > > would connect to specific hosts and try noop against the second Puppet > > > server. > > > > > I''d like to hear how other people manage this sort of thing. > > > > similarly but using environments: > http://docs.puppetlabs.com/guides/environment.html > > > > The nodes are made to do the noop run on their own and store their > > reports on the master. A simple script digests the reports. > > > > Cheers, > > Felix > > -- > 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. > >-- 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.