How are people upgrading puppet itself on their hosts that run puppetd? Can puppet be used to upgrade to a new puppet package via gem, rpm or some other package provider? How do you handle restarting? Just hoping theres a better way than "ssh and a for loop" or having to have another configuration management system installed.
--On Thursday, March 01, 2007 11:06 AM -0800 ben <pr0ncracker@gmail.com> wrote:> How are people upgrading puppet itself on their hosts that run puppetd? > > Can puppet be used to upgrade to a new puppet package via gem, rpm or > some other package provider? How do you handle restarting? > > Just hoping theres a better way than "ssh and a for loop" or having to > have another configuration management system installed.We use RPMs stored on our RedHat satellite server and DEBs stored on out aptitude server and currently we haven''t been doing automated updates to puppet packages, but doing so should be relatively easy, I think: service { "puppet": ensure => running, } package { "puppet-client": ensure => latest, notify => Service["puppet"], } That is of course theoretical, but worth trying. I''ll note, however, that the above syntax is a paraphrase of the service resource because there are variations between the name on Debian and RedHat that you need to account for (as well as the fact that the debian init doesn''t have a status so you have to hand specify that, etc) We have a similar issue with apache that I can show you a clip of if you are interested in seeing how we handled that. -- DK
On Thu, Mar 01, 2007 at 01:06:45PM -0800, Digant C Kasundra wrote:> service { "puppet": > ensure => running,hasrestart => true> }> package { "puppet-client": > ensure => latest, > notify => Service["puppet"], > }I think you''d need to ensure that your puppet init.d script has a restart function, and hasrestart is specified on the puppet service. This is just because puppetd will by default do a $initscript stop; $initscript start to restart the service. And of course, if you''ve just stopped the puppetd that''s going to start puppetd again, then you''d be slightly stuck. You could have a cron-job which would ping puppetd somehow, and restart if it''s not present, perhaps. -- Ceri Storey <cez@necrofish.org.uk> ''What I really want is "apt-get smite"'' --Rob Partington http://unix.culti.st/
You should be able to manage Puppet as you would basically any other service, but note that Puppet catches HUP and delays restarting until after the run is complete. Everything else should be similar. -- A great many people think they are thinking when they are merely rearranging their prejudices. -- William James --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Fri, 2007-03-02 at 09:43 -0600, Luke Kanies wrote:> You should be able to manage Puppet as you would basically any other > service, but note that Puppet catches HUP and delays restarting until > after the run is complete. Everything else should be similar.Which brings up the issue that at least the RH init script right now does a ''kill -HUP'' on restart, instead of stop && start; that should really be changed, but it would require that puppet does a reload instead of a restart for the puppet service in the manifest. David
On 3/2/07, David Lutterkort <dlutter@redhat.com> wrote:> On Fri, 2007-03-02 at 09:43 -0600, Luke Kanies wrote: > > You should be able to manage Puppet as you would basically any other > > service, but note that Puppet catches HUP and delays restarting until > > after the run is complete. Everything else should be similar. > > Which brings up the issue that at least the RH init script right now > does a ''kill -HUP'' on restart, instead of stop && start; that should > really be changed, but it would require that puppet does a reload > instead of a restart for the puppet service in the manifest. >I put in a bug a while ago with a patch to change the init script to have separate restart and reload commands. - Ian
On Fri, 2007-03-02 at 11:58 -0800, Ian Burrell wrote:> On 3/2/07, David Lutterkort <dlutter@redhat.com> wrote: > > On Fri, 2007-03-02 at 09:43 -0600, Luke Kanies wrote: > > > You should be able to manage Puppet as you would basically any other > > > service, but note that Puppet catches HUP and delays restarting until > > > after the run is complete. Everything else should be similar. > > > > Which brings up the issue that at least the RH init script right now > > does a ''kill -HUP'' on restart, instead of stop && start; that should > > really be changed, but it would require that puppet does a reload > > instead of a restart for the puppet service in the manifest. > > > > I put in a bug a while ago with a patch to change the init script to > have separate restart and reload commands.I know .. for some reason I only fixed the server script, not the client; I thought I had a good reason, but don''t remember why anymore. I''ll fix the client, too. David
On Fri, 2 Mar 2007, Ian Burrell wrote:> > Which brings up the issue that at least the RH init script right now > > does a ''kill -HUP'' on restart, instead of stop && start; that should > > really be changed, but it would require that puppet does a reload > > instead of a restart for the puppet service in the manifest. > > I put in a bug a while ago with a patch to change the init script to > have separate restart and reload commands.What I miss in puppet is the ability to notify a service to reload, instead of restart. It can be worked around by specifying the restart command to just reload the service, but it''s ugly. Best regards, Jozsef -- E-mail : kadlec@sunserv.kfki.hu, kadlec@blackhole.kfki.hu PGP key: http://www.kfki.hu/~kadlec/pgp_public_key.txt Address: KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
On Mar 3, 2007, at 6:18 AM, Kadlecsik Jozsi wrote:> > What I miss in puppet is the ability to notify a service to reload, > instead of restart. It can be worked around by specifying the restart > command to just reload the service, but it''s ugly.This would be pretty easy -- just add a parameter that allows you to select between the two. I just looked at it, and the only real complication is going through all of the providers and writing a method to handle the difference. Feel free to open a bug for this; I didn''t really know anyone wanted it, and I have to rewrite all of the service tests anyway, so it''d be a good opportunity to actually correctly test all of this code. As always, no guarantees when I''d get it done. If anyone wants to take a crack at it, here''s the patch to service.rb to get you started: Index: type/service.rb ==================================================================--- type/service.rb (revision 2258) +++ type/service.rb (working copy) @@ -262,6 +262,17 @@ newvalues(:true, :false) end + newparam :refresh do + desc "What service method to use when responding to events from + other resources. Options are ``reload`` and ``restart``, + and defaults to ``restart``. If you specify ``refresh``, + your init script clearly must have this method defined." + + newvalues(:reload, :restart) + + defaultto :restart + end + # Retrieve the default type for the current platform. def self.disableddefaulttype unless defined? @defsvctype @@ -350,7 +361,12 @@ def refresh # Only restart if we''re supposed to be running if ens = @parameters[:ensure] and ens.should == :running and ens.is == :running - provider.restart + if provider.respond_to?(self[:refresh]) + provider.send(self[:refresh]) + else + raise ArgumentError, "%s does not respond to %s" % + [self.ref, self[:refresh] + end end end end -- Get forgiveness now -- tomorrow you may no longer feel guilty. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com