I just ran into this problem myself. It seems that notifications are only
handled by Chef::Runner, in which the runner holds the list of
notifications (in order to check for duplicates) and only its run_action
command can write to the list of notifications.
So when you run, r.run_action you are running the resource without the
runner meaning the notification won't be handled.
I spent awhile trying to find a way to inject a resource into the runner's
list of resources or get access to the runner itself but for obvious
reasons you can't (or it is difficult).
One hack I found that does work is this,
ruby_block 'obligatory_foo' do
block do
delete.each do |f|
r = Chef::Resource::File.new((plugin_conf_path +
f).to_s, run_context)
r.run_action
self.notifies :reload, service
self.resolve_notification_references
end
end
end
This actually uses the parent ruby block 'obligatory_foo' to make the
notification call, in which self refers to the ruby_block[obligatory_foo].
Bryan
On Wed, Nov 23, 2011 at 3:59 PM, Allan Wind allan_wind@lifeintegrity.comwrote:
On 2011-11-14 18:44:35, Bryan McLellan wrote:
At run time
ruby_block "foo" do
block do
resources(:service => "apache2").run_action(:restart)
end
end
Any idea why this does not work for a dynamically defined
resource?
service = "service[daemon_foo]"
ruby_block 'obligatory_foo' do
block do
delete.each do |f|
r = Chef::Resource::File.new((plugin_conf_path +
f).to_s, run_context)
r.notifies :reload, service
r.run_action :delete
end
end
end
service 'daemon_foo' do
action [ :enable, :start ]
supports :reload => true
end
The delete works just fine but notification goes to /dev/null, and the
daemon
is restarted if the normal compile time resources trigger a reload.
/Allan
Allan Wind
Life Integrity, LLC
http://lifeintegrity.com