- From: Bryan Baugher <
>
- To:
- Subject: [chef] Re: Re: Re: Notifying Resources within Ruby Block Resource
- Date: Mon, 28 Nov 2011 15:46:24 -0600
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
<
">
> wrote:
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>
Archive powered by MHonArc 2.6.16.