That isn’t the same thing, it would a ruby block generating a
notification, not receiving one. It can certainly be done already
though (see the link I pasted) but it looks kind of clunky. There is
already a precedent with not_if and only_if of taking either a block
or “something else” too.

–Noah

On Jan 6, 2011, at 11:34 PM, Akzhan Abdulin wrote:

Is it already implemented

ruby_block do
code do
sleep 1
end
notifies :restart, resources(:service => :nginx80)
end

That isn’t the same thing, it would a ruby block generating a notification,
not receiving one. It can certainly be done already though (see the link I
pasted) but it looks kind of clunky. There is already a precedent with
not_if and only_if of taking either a block or “something else” too.

From the link you pasted, I’m not sure I understand your use-case here, Noah.

You want to trigger an action on a resource outside of another
resource triggering it through notification? If so:

At compile time

resources(:service => “apache2”).run_action(:restart)

At run time

ruby_block “foo” do
block do
resources(:service => “apache2”).run_action(:restart)
end
end

That isn’t the same thing, it would a ruby block generating a
notification,
not receiving one. It can certainly be done already though (see the
link I
pasted) but it looks kind of clunky. There is already a precedent
with
not_if and only_if of taking either a block or “something else” too.

From the link you pasted, I’m not sure I understand your use-case here,
Noah.

The use case is wanting to just have ruby code as a callback after a
resource updates. From talking to Daniel on IRC a bit I agree with him that
notifies doesn’t need to be overloaded like this, but having an
"after_update" and/or “after_error” callback point on all resources that
works similarly to before_migrate (etc) callbacks on Deploy would be cleaner
and address the same issue.