Issue #1014 has been updated by Jordan Sissel.
I think notify doing reload-or-restart oversimplifies things. There are other
possibly-confusing issues like when you notify a custom define. If that defines
a service and an exec, both will get notified. It's possible the
notify-custom-define issue is worth another ticket.
Some thoughts -
That said, if we want a reusable solution, I think it's about 'who' and 'how' -
who to notify, and how to notify them. The complexities in some applications
(apache) mean a human needs to understand when a restart is required or when a
reload is sufficient, which begs for some kind of syntax for describing this in
puppet.
It gets more complex because you can notify multiple things from a single
change. Notify is a special case in puppet in that it puts data on edges in the
graph, right? A notify is just a 'before' relationship plus some data with that
relationship (not sure how it's implemented in the code, but that's how I think
of it). What if we expanded that a bit? Are there other things we want to store
in the edges?
Alternately, notify can be thought of a as a way for one resource to message
another when that first resource changes.
Maybe we can expand on 2.6's -> and <- syntax? Something like
<pre>
# Syntax idea 1
File["/etc/apache2/sites-enabled/mysite.conf"] -> Service["apache2"]("reload")
Package["apache2"] -> reload Service["apache2"]("restart")
# the () syntax is optional, having (...) would imply a notify
# Syntax idea 2
File["/etc/apache2/sites-enabled/mysite.conf"] -> reload Service["apache2"]
Package["apache2"] -> restart Service["apache2"]("restart")
# The first token after the -> would be the 'how' in our notify
# Defining the service:
service {
"apache2":
ensure => ...,.
reload => "some command", # defaults to the provider's "reload"
restart => "some command", # just like today
hasrestart => ..., # just like today
hasreload => ...,
}
</pre>
Custom defines get a bit trickier and may require some new syntax. Maybe a new
meta resource called 'notification' or 'notify' ? Classes could use this, too!
<pre>
define foo() {
notify {
"restart": Exec["some command"];
"something": [Service["apache2"], AnotherResource["..."]];
}
}
class bar {
notify {
"config-updated": Service["apache2"];
}
}
# Now we could do:
MyResource["..."] -> "config-updated" Class["bar"]
MyResource["..."] -> "something" Foo["..."]
</pre>
Thoughts?
----------------------------------------
Feature #1014: Services should support 'reload' in addition to 'restart'
https://projects.puppetlabs.com/issues/1014
Author: Adrian Bridgett
Status: Needs design decision
Priority: Normal
Assignee: Nigel Kersten
Category: service
Target version: unplanned
Patch: None
Affected Puppet version: 0.24.7
Keywords:
Branch:
currently if a service needs kicking (e.g. a config file changed) you can
notify the service, but this leads to a restart. It would be nice if a reload
was done if the service was already running (although I suppose there are bound
to be some services which require restarts for some files, reloads for others).
A reload would be far faster (shorter service interruption) and potentially
more robust.
I'm looking at this since bind stop/start (I hadn't set "hasrestart") on Debian
etch can fail - it looks like stop command doesn't wait for bind to exit (I'll
raise a bug with Debian about that)
--
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.
