Delayed execution order error?

Chef Infra (archive)
1

Running on 10.18.2 here, and I see this in the log:

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

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?

2

On Thursday, February 21, 2013 at 7:57 AM, Jesse Campbell wrote:

Running on 10.18.2 here, and I see this in the log:

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

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

3

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.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

4

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.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

5

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 service Resource, 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.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.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

6

You should use the updated notification syntax for notifies:

notifies :restart, "service[foo]"

Instead of this:

notifies :restart, resources(:service => "foo") # or...
notifies :restart, resources("service[foo]")

The #resources() method here does a lookup of all the resources in the resource collection for the one named in order to set the notification, and it evaluates during the resource collection compilation phase. This is why you had to declare a resource with action :nothing prior to notifying it.

Note that the subscribes parameter requires the latter style using the #resources() method.

On Feb 21, 2013, at 10:17 AM, Tensibai 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.

--
Joshua Timberman
Technical Community Manager, Opscode, Inc
IRC, Skype, Twitter, Github: jtimberman

7

I do understand (I think).

What is unclear is why a service
ressource defined with action :start (for exemple) won't accept/honor
any notification to stop or restart.

I end up defining the service
ressource with action :nothing and having a log ressource notifying it
to start to ensure the service will be started at the end of chef run.

If someone has an idea :wink:

Tensibai

Le 2013-02-21 21:34, Joshua
Timberman a écrit :

You should use the updated notification syntax
for notifies:

notifies :restart, "service[foo]"

Instead of
this:

notifies :restart, resources(:service => "foo") # or...

notifies :restart, resources("service[foo]")

The #resources()
method here does a lookup of all the resources in the resource
collection for the one named in order to set the notification, and it
evaluates during the resource collection compilation phase. This is why
you had to declare a resource with action :nothing prior to notifying
it.

Note that the subscribes parameter requires the latter style
using the #resources() method.

On Feb 21, 2013, at 10:17 AM,
Tensibai 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.

8

On Feb 22, 2013, at 1:36 AM, Tensibai tensibai@iabis.net wrote:

What is unclear is why a service ressource defined with action :start (for exemple) won't accept/honor any notification to stop or restart.

I end up defining the service ressource with action :nothing and having a log ressource notifying it to start to ensure the service will be started at the end of chef run.

Would you please start a new thread with debug log output from a Chef run where the notification isn't working? Please include the platform, platform version and version of Chef.

Thanks!

9

From my original thread, I was seeing this when it got to delayed execution.

Should it be “not queuing” a delayed restart action, when the queued thing
was already run?

Or are you suggesting that switching to the new notifies :restart,
“service[jboss-17]” will fix it?

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

the recipe was something like this:

service “jboss-17” do
action :nothing
end

execute “standalone-17” do
command "cp
/nas_samcustomer/clusters/17/sam-app004/configuration/standalone.xmlsource
/nas_samcustomer/clusters/17/sam-app004/configuration/standalone.xml"
action :nothing
notifies :restart, resources(:service => “jboss-17”)
end

template
"/nas_samcustomer/clusters/17/sam-app004/configuration/standalone.xmlsource"
do
…
notifies :stop, resources(:service => “jboss-17”), :immediately
notifies :run, resources(:execute => “standalone-17”)
end

10

You don’t have to have action :nothing to be able to notify them.

Adam

From: Tensibai <tensibai@iabis.netmailto:tensibai@iabis.net>
Reply-To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Friday, February 22, 2013 12:36 AM
To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto:chef@lists.opscode.com>
Subject: [chef] Re: Re: delayed execution order error?

I do understand (I think).

What is unclear is why a service ressource defined with action :start (for exemple) won’t accept/honor any notification to stop or restart.

I end up defining the service ressource with action :nothing and having a log ressource notifying it to start to ensure the service will be started at the end of chef run.

If someone has an idea :wink:

Tensibai

Le 2013-02-21 21:34, Joshua Timberman a écrit :

You should use the updated notification syntax for notifies:

notifies :restart, "service[foo]"

Instead of this:

notifies :restart, resources(:service => "foo") # or...
notifies :restart, resources("service[foo]")

The #resources() method here does a lookup of all the resources in the resource collection for the one named in order to set the notification, and it evaluates during the resource collection compilation phase. This is why you had to declare a resource with action :nothing prior to notifying it.

Note that the subscribes parameter requires the latter style using the #resources() method.

On Feb 21, 2013, at 10:17 AM, 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.

11

Le 2013-02-22 17:14, Joshua Timberman a écrit :

On Feb 22,
2013, at 1:36 AM, Tensibai tensibai@iabis.net wrote:

What is
unclear is why a service ressource defined with action :start (for
exemple) won't accept/honor any notification to stop or restart. I end
up defining the service ressource with action :nothing and having a log
ressource notifying it to start to ensure the service will be started at
the end of chef run.

Would you please start a new thread with debug
log output from a Chef run where the notification isn't working? Please
include the platform, platform version and version of Chef.

Thanks!

In fact the :nothing works great for me, my main interest is
trying to understand the original thread problem.
IIRC the log from the
same thread from yesterday is clearly this kind of question.

After
testing in simple cookbook, it works great, "maybe" the problem is
withing a lwrp or something else...

So, I'm really not sure of where
the problem is and I'll keep that in mind if I get into this again with
enough time to track it down clearly.

Regards.