[chef] RE : *** PROBABLY SPAM *** Re: Re: Re: Re: Re: Re: delayed execution order error?

[Tensibai < >]

Well it's more my rule of thumb than something seen. But I always set service ressources with action nothing and use notifications.

In the matter of understanding it I would say:

If the ressource has an action different from nothing do it when its time in convergence and then forget it.

If action is nothing keep it in mind for possible future use.

I'm far from sure this is the wanted state but it works for me and I do use it with log ressources for notifications when needed to keep control and trace of what's done within the client run.

I hope that helps ;)

(sent from a phone, disregards mistyping and so... Bla bla bla :p )

Envoyé depuis un mobile Samsung

Peter Norton <
 > a écrit :

The notifications as documented on that page doesn't seem to directly corroborate or contradict what I read from Tensibai, which is that if a service resource specifies that its action is to :restart, that will happen immediately.  Further notifications to that service to restart will be ignored because it's happened.

This would imply that the service resource's action is a type of notification, which I can't find explicitly documented.

On Thu, Feb 21, 2013 at 1:34 PM, Warren Bain < " target="_blank"> > wrote:

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 < "> > 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 < "> <mailto: "> >> 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 < "> <mailto: "> >> 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