Is there a way to quiesce the puppet daemon, such that it stays running, but does not run updates, until instructed again to do so? We have puppet deploying our software, and would like to quiesce puppetd so that it doesn''t restart services etc until after the upgrade is done. Doug. -- 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.
Douglas Garstang wrote:> Is there a way to quiesce the puppet daemon, such that it stays > running, but does not run updates, until instructed again to do so? > > We have puppet deploying our software, and would like to quiesce > puppetd so that it doesn''t restart services etc until after the > upgrade is done. > > Doug. > >Use "puppetd --disable" and "puppetd --enable". -Alan -- 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 Fri, Mar 19, 2010 at 2:33 PM, Alan Sparks <asparks@doublesparks.net> wrote:> Douglas Garstang wrote: >> Is there a way to quiesce the puppet daemon, such that it stays >> running, but does not run updates, until instructed again to do so? >> >> We have puppet deploying our software, and would like to quiesce >> puppetd so that it doesn''t restart services etc until after the >> upgrade is done. >> >> Doug. >> >> > > Use "puppetd --disable" and "puppetd --enable".I... guess... that will do. Not ideal though as it stops puppet from running new updates by making it think it''s already running. It also doesn''t log to syslog that it''s currently disabled, so it makes it tough to see if it''s been running for a long time and is completely borked, or just locked for an upgrade. Doug -- 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.
Douglas Garstang writes: > On Fri, Mar 19, 2010 at 2:33 PM, Alan Sparks <asparks@doublesparks.net> wrote: > > Douglas Garstang wrote: > >> Is there a way to quiesce the puppet daemon, such that it stays > >> running, but does not run updates, until instructed again to do so? > >> > >> We have puppet deploying our software, and would like to quiesce > >> puppetd so that it doesn''t restart services etc until after the > >> upgrade is done. > > > > Use "puppetd --disable" and "puppetd --enable". > > I... guess... that will do. Not ideal though as it stops puppet from > running new updates by making it think it''s already running. It also > doesn''t log to syslog that it''s currently disabled, so it makes it > tough to see if it''s been running for a long time and is completely > borked, or just locked for an upgrade. Why not have the service require something that will only be present once the upgrade is complete? -- 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 Fri, Mar 19, 2010 at 2:49 PM, Steven VanDevender <stevev@uoregon.edu> wrote:> Douglas Garstang writes: > > On Fri, Mar 19, 2010 at 2:33 PM, Alan Sparks <asparks@doublesparks.net> wrote: > > > Douglas Garstang wrote: > > >> Is there a way to quiesce the puppet daemon, such that it stays > > >> running, but does not run updates, until instructed again to do so? > > >> > > >> We have puppet deploying our software, and would like to quiesce > > >> puppetd so that it doesn''t restart services etc until after the > > >> upgrade is done. > > > > > > Use "puppetd --disable" and "puppetd --enable". > > > > I... guess... that will do. Not ideal though as it stops puppet from > > running new updates by making it think it''s already running. It also > > doesn''t log to syslog that it''s currently disabled, so it makes it > > tough to see if it''s been running for a long time and is completely > > borked, or just locked for an upgrade. > > Why not have the service require something that will only be present > once the upgrade is complete?I''m not sure, but how would we get puppet to stop the service, run a database upgrade script (and maybe some other stuff), and then restart the service all in the same puppet run? Doug. -- 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.
Douglas Garstang writes: > On Fri, Mar 19, 2010 at 2:49 PM, Steven VanDevender <stevev@uoregon.edu> wrote: > > Douglas Garstang writes: > > > On Fri, Mar 19, 2010 at 2:33 PM, Alan Sparks <asparks@doublesparks.net> wrote: > > > > Douglas Garstang wrote: > > > >> Is there a way to quiesce the puppet daemon, such that it stays > > > >> running, but does not run updates, until instructed again to do so? > > > >> > > > >> We have puppet deploying our software, and would like to quiesce > > > >> puppetd so that it doesn''t restart services etc until after the > > > >> upgrade is done. > > > > > > > > Use "puppetd --disable" and "puppetd --enable". > > > > > > I... guess... that will do. Not ideal though as it stops puppet from > > > running new updates by making it think it''s already running. It also > > > doesn''t log to syslog that it''s currently disabled, so it makes it > > > tough to see if it''s been running for a long time and is completely > > > borked, or just locked for an upgrade. > > > > Why not have the service require something that will only be present > > once the upgrade is complete? > > I''m not sure, but how would we get puppet to stop the service, run a > database upgrade script (and maybe some other stuff), and then restart > the service all in the same puppet run? I''m not sure how you''d do that all in the same puppet run, or whether that would even be desirable. But you can certainly use "require" to ensure that things happen in a particular order, even if it takes multiple Puppet runs to work through all the steps. -- 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 Fri, Mar 19, 2010 at 3:03 PM, Steven VanDevender <stevev@uoregon.edu> wrote:> Douglas Garstang writes: > > On Fri, Mar 19, 2010 at 2:49 PM, Steven VanDevender <stevev@uoregon.edu> wrote: > > > Douglas Garstang writes: > > > > On Fri, Mar 19, 2010 at 2:33 PM, Alan Sparks <asparks@doublesparks.net> wrote: > > > > > Douglas Garstang wrote: > > > > >> Is there a way to quiesce the puppet daemon, such that it stays > > > > >> running, but does not run updates, until instructed again to do so? > > > > >> > > > > >> We have puppet deploying our software, and would like to quiesce > > > > >> puppetd so that it doesn''t restart services etc until after the > > > > >> upgrade is done. > > > > > > > > > > Use "puppetd --disable" and "puppetd --enable". > > > > > > > > I... guess... that will do. Not ideal though as it stops puppet from > > > > running new updates by making it think it''s already running. It also > > > > doesn''t log to syslog that it''s currently disabled, so it makes it > > > > tough to see if it''s been running for a long time and is completely > > > > borked, or just locked for an upgrade. > > > > > > Why not have the service require something that will only be present > > > once the upgrade is complete? > > > > I''m not sure, but how would we get puppet to stop the service, run a > > database upgrade script (and maybe some other stuff), and then restart > > the service all in the same puppet run? > > I''m not sure how you''d do that all in the same puppet run, or whether > that would even be desirable. But you can certainly use "require" to > ensure that things happen in a particular order, even if it takes > multiple Puppet runs to work through all the steps.I don''t think it''s possible in the same run. I''m quite familar with require. I''ve spent months trying to get all the dependancies correct on our software. It''s been a nightmare and I''m actually afraid to touch it now for fear of breaking it, as it''s so damn complicated. But... I think I''ll have to stick with disabling puppet before an upgrade, performing the upgrade and then enabling puppet. Doug. -- 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 solved this by using capistrano tasks to stop puppetd across the hosts, run upgrades, then restart puppetd. Capistrano (or other similar tools) seem to be easier for these type of operational configuration changes vs. trying to model this within puppet. On Fri, Mar 19, 2010 at 3:05 PM, Douglas Garstang <doug.garstang@gmail.com>wrote:> On Fri, Mar 19, 2010 at 3:03 PM, Steven VanDevender <stevev@uoregon.edu> > wrote: > > Douglas Garstang writes: > > > On Fri, Mar 19, 2010 at 2:49 PM, Steven VanDevender < > stevev@uoregon.edu> wrote: > > > > Douglas Garstang writes: > > > > > On Fri, Mar 19, 2010 at 2:33 PM, Alan Sparks < > asparks@doublesparks.net> wrote: > > > > > > Douglas Garstang wrote: > > > > > >> Is there a way to quiesce the puppet daemon, such that it > stays > > > > > >> running, but does not run updates, until instructed again to > do so? > > > > > >> > > > > > >> We have puppet deploying our software, and would like to > quiesce > > > > > >> puppetd so that it doesn''t restart services etc until after > the > > > > > >> upgrade is done. > > > > > > > > > > > > Use "puppetd --disable" and "puppetd --enable". > > > > > > > > > > I... guess... that will do. Not ideal though as it stops puppet > from > > > > > running new updates by making it think it''s already running. It > also > > > > > doesn''t log to syslog that it''s currently disabled, so it makes > it > > > > > tough to see if it''s been running for a long time and is > completely > > > > > borked, or just locked for an upgrade. > > > > > > > > Why not have the service require something that will only be present > > > > once the upgrade is complete? > > > > > > I''m not sure, but how would we get puppet to stop the service, run a > > > database upgrade script (and maybe some other stuff), and then restart > > > the service all in the same puppet run? > > > > I''m not sure how you''d do that all in the same puppet run, or whether > > that would even be desirable. But you can certainly use "require" to > > ensure that things happen in a particular order, even if it takes > > multiple Puppet runs to work through all the steps. > > I don''t think it''s possible in the same run. I''m quite familar with > require. I''ve spent months trying to get all the dependancies correct > on our software. It''s been a nightmare and I''m actually afraid to > touch it now for fear of breaking it, as it''s so damn complicated. > > But... I think I''ll have to stick with disabling puppet before an > upgrade, performing the upgrade and then enabling puppet. > > Doug. > > -- > 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<puppet-users%2Bunsubscribe@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.
Agreed, but the documentation for capistrano is horrible. On Fri, Mar 19, 2010 at 3:23 PM, Kevin Rae <kevin.rae@gmail.com> wrote:> We solved this by using capistrano tasks to stop puppetd across the hosts, > run upgrades, then restart puppetd. Capistrano (or other similar tools) > seem to be easier for these type of operational configuration changes vs. > trying to model this within puppet. > > On Fri, Mar 19, 2010 at 3:05 PM, Douglas Garstang <doug.garstang@gmail.com> > wrote: >> >> On Fri, Mar 19, 2010 at 3:03 PM, Steven VanDevender <stevev@uoregon.edu> >> wrote: >> > Douglas Garstang writes: >> > > On Fri, Mar 19, 2010 at 2:49 PM, Steven VanDevender >> > <stevev@uoregon.edu> wrote: >> > > > Douglas Garstang writes: >> > > > > On Fri, Mar 19, 2010 at 2:33 PM, Alan Sparks >> > <asparks@doublesparks.net> wrote: >> > > > > > Douglas Garstang wrote: >> > > > > >> Is there a way to quiesce the puppet daemon, such that it >> > stays >> > > > > >> running, but does not run updates, until instructed again to >> > do so? >> > > > > >> >> > > > > >> We have puppet deploying our software, and would like to >> > quiesce >> > > > > >> puppetd so that it doesn''t restart services etc until after >> > the >> > > > > >> upgrade is done. >> > > > > > >> > > > > > Use "puppetd --disable" and "puppetd --enable". >> > > > > >> > > > > I... guess... that will do. Not ideal though as it stops puppet >> > from >> > > > > running new updates by making it think it''s already running. It >> > also >> > > > > doesn''t log to syslog that it''s currently disabled, so it makes >> > it >> > > > > tough to see if it''s been running for a long time and is >> > completely >> > > > > borked, or just locked for an upgrade. >> > > > >> > > > Why not have the service require something that will only be >> > present >> > > > once the upgrade is complete? >> > > >> > > I''m not sure, but how would we get puppet to stop the service, run a >> > > database upgrade script (and maybe some other stuff), and then >> > restart >> > > the service all in the same puppet run? >> > >> > I''m not sure how you''d do that all in the same puppet run, or whether >> > that would even be desirable. But you can certainly use "require" to >> > ensure that things happen in a particular order, even if it takes >> > multiple Puppet runs to work through all the steps. >> >> I don''t think it''s possible in the same run. I''m quite familar with >> require. I''ve spent months trying to get all the dependancies correct >> on our software. It''s been a nightmare and I''m actually afraid to >> touch it now for fear of breaking it, as it''s so damn complicated. >> >> But... I think I''ll have to stick with disabling puppet before an >> upgrade, performing the upgrade and then enabling puppet. >> >> Doug. >> >> -- >> 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. >-- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garstang@gmail.com Cell: +1-805-340-5627 -- 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.
>> Use "puppetd --disable" and "puppetd --enable". > > I... guess... that will do. Not ideal though as it stops puppet from > running new updates by making it think it''s already running. It also > doesn''t log to syslog that it''s currently disabled, so it makes it > tough to see if it''s been running for a long time and is completely > borked, or just locked for an upgrade.Looks like this could be improved from the puppet side. Is there a bugreport filed for that? cheers pete -- 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 run puppet from a wrapper via cron that (among other things) looks to see if the server is in maintenance mode ( test -f /.maint ) Puppet only runs if that file exists. The wrapper complains if the maint file is > 24 hours old John On 20 March 2010 08:32, Douglas Garstang <doug.garstang@gmail.com> wrote:> Is there a way to quiesce the puppet daemon, such that it stays > running, but does not run updates, until instructed again to do so? > > We have puppet deploying our software, and would like to quiesce > puppetd so that it doesn''t restart services etc until after the > upgrade is done. > > Doug. > > -- > 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- John Warburton Ph: 0417 299 600 Email: jwarburton@gmail.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.
ls -l /var/lib/puppet/state/puppetdlock (path may vary..) If its 0 bytes, either you ran out of disk space or its --disable''d. If its got a pid, that is the puppet daemon pid that is running an update. If it is missing, either puppet is not running at all or it is not running an update. On Fri, Mar 19, 2010 at 5:44 PM, Douglas Garstang <doug.garstang@gmail.com>wrote:> On Fri, Mar 19, 2010 at 2:33 PM, Alan Sparks <asparks@doublesparks.net> > wrote: > > Douglas Garstang wrote: > >> Is there a way to quiesce the puppet daemon, such that it stays > >> running, but does not run updates, until instructed again to do so? > >> > >> We have puppet deploying our software, and would like to quiesce > >> puppetd so that it doesn''t restart services etc until after the > >> upgrade is done. > >> > >> Doug. > >> > >> > > > > Use "puppetd --disable" and "puppetd --enable". > > I... guess... that will do. Not ideal though as it stops puppet from > running new updates by making it think it''s already running. It also > doesn''t log to syslog that it''s currently disabled, so it makes it > tough to see if it''s been running for a long time and is completely > borked, or just locked for an upgrade. > > Doug > > -- > 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<puppet-users%2Bunsubscribe@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.
On Sun, Mar 21, 2010 at 10:03 PM, John Warburton <jwarburton@gmail.com> wrote:> We run puppet from a wrapper via cron that (among other things) looks to see > if the server is in maintenance mode ( test -f /.maint ) > > Puppet only runs if that file exists. The wrapper complains if the maint > file is > 24 hours oldHow do you make puppet not run if the file exists INSIDE puppet though? Doug. -- 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.
The /.maint file is managed manually by the sys admin team - totally independent of puppet - that''s the point John On 24 March 2010 07:14, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Sun, Mar 21, 2010 at 10:03 PM, John Warburton <jwarburton@gmail.com> > wrote: > > We run puppet from a wrapper via cron that (among other things) looks to > see > > if the server is in maintenance mode ( test -f /.maint ) > > > > Puppet only runs if that file exists. The wrapper complains if the maint > > file is > 24 hours old > > How do you make puppet not run if the file exists INSIDE puppet though? > > Doug. > >-- 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.