Hi Bryan – here’s a gist with the recipe as I finally got it working.
I think you’re probably right about why the template couldn’t notify the
supervisor_service – the application recipe is complex and probably not
creating the supervisor_service until convergence time.
Two parts I still really don’t understand. Why the before_restart and
after_restart callbacks didn’t seem to ever do anything – never fired as
far as I could see. I even tried various chef versions from 10.12 to 10.16
on Andrea’s hint.
Also, it makes no sense to me why the notifies commands need the :immediate
modifier to work. Without it, the notification got processed (I saw
Chef::Log messages within them), but the
execute command which did the
real work just got skipped.
I think I understand why the top-level
notifies within the application
didn’t do anything – that would only fire if the application resource
itself changed, which basically never happens. It’s the sub-resources that
are getting modified during code deployments. Is that right?
Thanks for your help!
On Wed, Oct 24, 2012 at 6:36 PM, Bryan McLellan email@example.com wrote:
Could you gist a recipe to represent your issue?
Since 0.9.10 (CHEF-899 ) you’ve been able to notify a resource that
hasn’t been created yet because the notifications get resolved just
before convergence. Similar support was added in 10.14.0 for
subscribes (CHEF-1994 ). The most common situation where this is
still a problem is when a resource is created during convergence (like
in a ruby_block) that needs to be notified by another resource. When
you’re looking at a recipe, their visual proximity makes it feel like
it should work but we’re talking about pretty disparate points in the
On Wed, Oct 24, 2012 at 4:32 PM, Leo Dirac (SR)
Peter’s suggestion worked for me, but I’m confused by it. If I don’t use
the :immediately timing option on notifies, it doesn’t work. I see in
log “Processing supervisor_service[srapiworker] action restart” followed
a debug log line from the provider, but nothing happens. If I use
:immediately the same log line is followed by the service actually
restarting through the provider’s execute command. This doesn’t make any
sense to me.
Why is the :immediately needed to prevent the messages becoming no-ops?
Having dug into CHEF-3493 a lot myself, I suspect you’re working
inside another resource and it’s possible that is putting you in a
recipe_eval which puts you in another run context and the queued
notifications don’t get run because that run_context isn’t a complete
chef run. Dan mentioned recipe_eval was a hack for something a bit
Seeing your recipe would help a lot though.