[chef] Re: Notifies with an unsupported action

[Bryan McLellan < >]

On Tue, Jan 11, 2011 at 12:13 PM, Mark J. Reed 
<
 >
 wrote:
> The current behavior is defensible; the "supports" declaration is
> clearly a lie for any Upstart service.  I'm just trying to work around
> an issue (http://tickets.opscode.com/browse/CHEF-1971) wherein
> "restart" doesn't work the way Chef expects it to for Upstart
> services.

For starters, we should fix CHEF-1971 so that restart using upstart
does fail so much.

Have you tried using restart_command to workaround?

service "foo" do
  restart_command "true"
end

'supports' started out as a way to describe what actions the init
script behind the provider supported as we couldn't easily detect
this. It's actually kind of stunning how many ways we've propped up
sysvinit over the years to do things it wasn't ever designed for. I'm
reluctant to modify 'supports' to specify what actions are allowed. Is
there a common use case for this, particularly outside of this
workaround?

> I wonder if it would make more sense to handle 'supports' at a higher
> level and reject any attempt to send an action that is declared as
> unsupported.  Or at least have the service resource itself, rather
> than the individual providers, handle things like translating restart
> into stop/start.

We shouldn't assume that restart is a matter of a successful stop
followed by a start because init systems are become more and more
complex and there may very well be actions performed by a restart that
are unique. I admit, this is likely rare, and in this case the user
could use restart_command to get what they wanted. However there is
the principle of least surprise. If I ask Chef to restart a service
using a particular provider, I would expect it to use restart, where
possible.

Otherwise, I agree with the rest of the thread; the service resource
should probably chatter a little more about what it is doing.

Bryan