Puppet module restart puppet client or not?

36 views
Skip to first unread message

Ugo Bellavance

unread,
Dec 12, 2012, 1:57:00 PM12/12/12
to puppet...@googlegroups.com
Hi,

I've built a puppet module myself to manage puppet.conf and I use a subscribe for the service, so it restarts the client whenever puppet.conf changes.  I think I shouldn't but I'd like to have a confirmation.  The fact that foreman sees a failure upon a change in puppet.conf makes me think even more that I am wrong...

Thanks,

Ryan Coleman

unread,
Dec 12, 2012, 6:13:41 PM12/12/12
to puppet...@googlegroups.com
If the service was successfully restarted, it should register as a successful change. That's normal behavior. Is that not what you see?
 

Thanks,

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/13IctiK6RhQJ.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.



--
Ryan Coleman | Modules & Forge | @ryanycoleman | ryancoleman in #puppet
 


Ugo Bellavance

unread,
Dec 12, 2012, 7:41:12 PM12/12/12
to puppet...@googlegroups.com


On Wednesday, December 12, 2012 6:13:41 PM UTC-5, Ryan Coleman wrote:



On Wed, Dec 12, 2012 at 10:57 AM, Ugo Bellavance <ug...@lubik.ca> wrote:
Hi,

I've built a puppet module myself to manage puppet.conf and I use a subscribe for the service, so it restarts the client whenever puppet.conf changes.  I think I shouldn't but I'd like to have a confirmation.   
The fact that foreman sees a failure upon a change in puppet.conf makes me think even more that I am wrong...

If the service was successfully restarted, it should register as a successful change. That's normal behavior. Is that not what you see?

Makes sense, but I think Foreman may have a way to determine whether the report is Applied, Restarted, Failed, Restart Failure, Skipped or Pending.  Maybe it shows Failed because it doesn't see the "Finished catalog run in 0.64 seconds" at the end?  I guess maybe I should ask to the Foreman group, but I was mostly wondering whether it was a good idea or not to restart puppet when changing puppet.conf.

Thanks,

Ugo

Matthew Burgess

unread,
Dec 13, 2012, 5:43:14 AM12/13/12
to puppet...@googlegroups.com
On Thu, Dec 13, 2012 at 12:41 AM, Ugo Bellavance <ug...@lubik.ca> wrote:

> I guess maybe I should ask to the Foreman group,
> but I was mostly wondering whether it was a good idea or not to restart
> puppet when changing puppet.conf.

I think it would be a bad idea not to. Otherwise you've got a process
running under a different configuration than what is on disk, so when
it doesn't look like it's behaving like the config suggests it should,
it can cause a lot of head-scratching!

Note the advice in the thread at
https://groups.google.com/d/msg/puppet-users/LViZFxc5ZAE/2yWRRixDoOQJ
though, about how to get puppet to successfully restart the agent!

Regards,

Matt.

Ugo Bellavance

unread,
Dec 13, 2012, 7:03:20 PM12/13/12
to puppet...@googlegroups.com
On Thursday, December 13, 2012 5:43:14 AM UTC-5, Matthew Burgess wrote:
On Thu, Dec 13, 2012 at 12:41 AM, Ugo Bellavance <ug...@lubik.ca> wrote:

> I guess maybe I should ask to the Foreman group,
> but I was mostly wondering whether it was a good idea or not to restart
> puppet when changing puppet.conf.

I think it would be a bad idea not to.  Otherwise you've got a process
running under a different configuration than what is on disk, so when
it doesn't look like it's behaving like the config suggests it should,
it can cause a lot of head-scratching!


That rises two questions in my mind:

  1. In my understanding, puppetmaster catches any changes in the manifests without needing a restart, why can't the puppet client reload its puppet.conf parameters at the next run?
  2. Why puppet can't use the "reload" option of most current daemons' init scripts?  I think there should be a parameter "hasreload", similar to "hasrestart", saying that the init script supports the use of the "reload" argument.  This would avoid this kind of problem, and people wouldn't have to redefine the restart command.
Ugo

Eric Sorenson

unread,
Dec 14, 2012, 2:08:50 AM12/14/12
to puppet...@googlegroups.com


On Thursday, December 13, 2012 4:03:20 PM UTC-8, Ugo Bellavance wrote:

That rises two questions in my mind:

  1. In my understanding, puppetmaster catches any changes in the manifests without needing a restart, why can't the puppet client reload its puppet.conf parameters at the next run?

There's a pretty big distinction between the puppetmaster watching -manifests- that it uses and watching/changing -config settings- : the first one is pretty safe (controlled by the `filetimeout` setting and mostly works), the second is pretty perilous when running in a monolithic long-lived ruby process. 

There is a lot of tangled stuff around puppet early bootstrapping and initialization that is a major focus of work for the upcoming 3.1 release: http://projects.puppetlabs.com/versions/288  but even if after that's cleared up, the edge cases are pretty brutal -- For example if the value (or heck, the contents) of $libdir changes and new versions of plugins are available, they can't be reliably reloaded into the same ruby process.  See stuff like http://projects.puppetlabs.com/issues/4248#note-29  , and the long list of related issues on http://projects.puppetlabs.com/issues/7316

IMO this is the biggest drawback to long-running puppet daemon processes compared to periodic instantiation via cron / god / daemontools /etc: you just cannot be confident that the interpreter state is actually going to reinitialize cleanly if something big changes underneath it.
 
  1. Why puppet can't use the "reload" option of most current daemons' init scripts?  I think there should be a parameter "hasreload", similar to "hasrestart", saying that the init script supports the use of the "reload" argument.  This would avoid this kind of problem, and people wouldn't have to redefine the restart command.
Look back through some of the prior discussions on this topic; I can understand the desire but previous discussions have raised some legitimate issues that nobody's code so far has addressed --


Looks like the most recent state of play was Daniel Pittman's proposal here: http://projects.puppetlabs.com/issues/3323#note-14
which seems nice & clean (add support for `hasrestart => graceful`). 

eric0
Reply all
Reply to author
Forward
0 new messages