opscode-cookbooks/bluepill — pull request #17 by faizk (2013-08-26 07:02:42+00:00)
Title: [COOK-3503] Supporting why-run for the bluepill_service LWRP.

This commit implements `why-run` support for the `bluepill_service` LWRP.

I found that on converge, the actions taken by the LWRP (if any were taken at all)
go unreported - this stands out when you run `chef-client` with `-F doc`.
While the resource is marked as updated and picked up by report handlers,
it isn't clear what changed (did the bluepill-based service reload, or restart?)

I also found that implementing `why-run` support has the added effect of 'fixing' this -
it causes the actual actions taken by the LWRP `bluepill_service` to
be reported during a converge:

To illustrate, assume we have in a `foo` cookbook something like:

```ruby
# Keep some foo daemon running - with bluepill

template '/etc/bluepill/foo.pill' do
source 'foo.pill.erb'
notifies :reload, 'bluepill_service[foo]'
end

bluepill_service "foo" do
action [:enable, :load, :start]
end

# we want to restart foo when this file changes.
template '/etc/foo.conf' do
source 'foo.conf.erb'
notifies :restart, 'bluepill_service[foo]'
# bluepill_service[foo] properly restarts if this file changes,
# but this fact isn't clearly reported.
end
```

Assume we do a converge and the contents of `foo.conf` are updated. In either case, `bluepill_service` is properly restarted as expected, but this fact isn't clearly reported:

(without why-run support)

$ chef-client -F doc
# .. output ...
Recipe: foo::default
* bluepill_service[foo] action restart
(nothing!)

(if why-run were supported )

$ chef-client -F doc
# .. output ...
Recipe: foo::default
* bluepill_service[foo] action restart
- restart bluepill_service[foo]