Peter,
Resources are converged in the order they are defined. If a service is to start our restart only in response to another resource being ready such as a template, then use the :nothing action and instead notify.
Examples are further down this page:
http://docs.opscode.com/resource_common_notifications.html
Wazza
Warren Bain
http://ninefold.com
Australia’s cloud
direct: +61 2 8221 7729
mobile: +61 414 867 559
follow: http://twitter.com/thoughtcroft
Peter Norton pn+chef-list@knewton.com wrote:
Tensibai,
I thought that if the service was defined to restart then it would be deferred to the end of the run. Is this just not totally defined yet? I am trying to read http://docs.opscode.com/resource_service.html, but it’s a lot. So far I don’t see anything explicitly stating what the timing is of the action or what the consequences are (e.g. deferred actions are ignored if a restart is the defined action). And in addition, if :start or :enable are provided as the action, what impact (if any) would that have on further actions? Most cookbooks don’t provide “action :nothing” for a service in their default cookbook.
Thanks,
-Peter
-Peter
On Thu, Feb 21, 2013 at 12:17 PM, Tensibai <tensibai@iabis.netmailto:tensibai@iabis.net> wrote:
Hum… I remember having to define services with action :nothing to be able to notify them.
I’m quite sure you have an action :restart inside the service declaration. Fot what I understand, the service is define to restart, it does restart and ignore any notification as it has already do what it was suppose to do (restart).
Set action to nothing in your service and notifications for restart will be ok I think.
Tensibai
Le 2013-02-21 17:29, Jesse Campbell a écrit :
with a couple extra lines:
sam-app004 chef-client[31577]: 1: template[/nas_samcustomer/clusters/17/sam-app004/configuration/h300000017.properties] sending restart action to service[jboss-17] (delayed)
sam-app004 chef-client[31577]: 1: Processing service[jboss-17] action restart (/var/cache/chef/cookbooks/
sam/providers/jboss7cluster.rb line 23)
sam-app004 chef-client[31577]: 1: service[jboss-17] restarted
sam-app004 chef-client[31577]: 1: template[/nas_samcustomer/clusters/17/sam-app004/configuration/standalone.xmlsource] sending run action to execute[standalone-17] (delayed)
sam-app004 chef-client[31577]: 1: Processing execute[standalone-17] action run (/var/cache/chef/cookbooks/sam/providers/jboss7cluster.rb line 148)
sam-app004 chef-client[31577]: 1: execute[standalone-17] ran successfully
sam-app004 chef-client[31577]: 1: execute[standalone-17] not queuing delayed action restart on service[jboss-17] (delayed), as it’s already been queued
sam-app004 chef-client[31577]: 1: Chef Run complete in 137.192547 seconds
-Jesse
On Thu, Feb 21, 2013 at 11:21 AM, Daniel DeLeo <dan@kallistec.commailto:dan@kallistec.com> wrote:
On Thursday, February 21, 2013 at 7:57 AM, Jesse Campbell wrote:
so… it doesn’t queue a restart on a service because it was “already queued”… but the queued restart already happened.
end result: the service doesn’t come up with the proper configuration
Is this a bug in 10.18? I’m resolving my issue by setting the template run of execute standalone to happen immediately, but this seems like it should be looked at?
That’s a delayed notification, you wouldn’t see it until the end of the run, and you clipped the part of the logs that show the delayed notifications, so I can’t really say if the behavior is correct or not.
–
Daniel DeLeo