Issue #7273 has been updated by Nigel Kersten.
Ryan Conway wrote:
> Ah I see, that still feels suboptimal to me, in that we have to create a lot
> of extra code just to manage Puppet properly, when it should really (in my
> opinion) be capable of managing itself.
>
> I really think we should be able to take the vanilla Puppet gem, point it at
> a master and change whatever configuration we like, all the while with Puppet
> handling notifies to restart itself properly.
The problem is that "properly" has multiple meanings. Sometimes it's desirable
to not apply settings until the next run, sometimes it's desirable to abort the
current run with no sense of success/failure, sometimes it's desirable to abort
with a failure status.
I'd definitely like to see a more 'native' solution, but feel that implementing
signals is a good first step to getting there.
Particularly if we have a good signal type, this isn't such a bad solution,
imagine something like (completely off the top of my head):
<pre>
signal { "puppetd":
ensure => "USR1",
refreshonly => "true",
target => all, # this could be first, last, all.
}
</pre>
----------------------------------------
Bug #7273: Modifying puppet.conf causes 'reparsing config' and TERM signal
results in shutdown of daemon
https://projects.puppetlabs.com/issues/7273
Author: Randall Hansen
Status: Needs More Information
Priority: Normal
Assignee: Nigel Kersten
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
... waiting for details from Ryan Conway ...
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
