Wait attribute for execute resource


#1

Hi,

What do you think about another attribute for the execute resource?
It’s wait or while.

Some processes as virsh start is async.
Using second execute resource is not short.

Example:

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
end

execute “while virsh domstate #{ name } | grep -q running ; do : ; done”

but with new attribute it could be

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
wait_if "virsh domstate #{ name } | grep -q running"
end


Daneel S. Yaitskov


#2

Maybe wait_for rather than if? Also, going to need to control timeout for
the wait to avoid deadlocks.
On Nov 29, 2013 11:27 AM, “Daneel Yaitskov” rtfm.rtfm.rtfm@gmail.com
wrote:

Hi,

What do you think about another attribute for the execute resource?
It’s wait or while.

Some processes as virsh start is async.
Using second execute resource is not short.

Example:

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
end

execute “while virsh domstate #{ name } | grep -q running ; do : ; done”

but with new attribute it could be

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
wait_if "virsh domstate #{ name } | grep -q running"
end


Daneel S. Yaitskov


#3

Yes, wait_for is the way to go.

We need to have a back off with a timeout.

Something like:
wait_for foo for N_SECONDS with N checks

Based on the timeout and the number of checks, an exponential back off will
be run.

On Fri, Nov 29, 2013 at 11:34 AM, Adam Jacob adam@opscode.com wrote:

Maybe wait_for rather than if? Also, going to need to control timeout for
the wait to avoid deadlocks.
On Nov 29, 2013 11:27 AM, “Daneel Yaitskov” rtfm.rtfm.rtfm@gmail.com
wrote:

Hi,

What do you think about another attribute for the execute resource?
It’s wait or while.

Some processes as virsh start is async.
Using second execute resource is not short.

Example:

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
end

execute “while virsh domstate #{ name } | grep -q running ; do : ; done”

but with new attribute it could be

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
wait_if "virsh domstate #{ name } | grep -q running"
end


Daneel S. Yaitskov


#4

Whats the reason for this being part of the resource instead of its own resource that just blocks the converge until the condition passes, or an action on the resource (a la https://github.com/balanced-cookbooks/jenkins/blob/master/libraries/jenkins.rb#L174-L186)?

–Noah

On Nov 29, 2013, at 2:40 PM, Jordan Dea-Mattson jdm-lists@dea-mattson.com wrote:

Yes, wait_for is the way to go.

We need to have a back off with a timeout.

Something like:
wait_for foo for N_SECONDS with N checks

Based on the timeout and the number of checks, an exponential back off will be run.

On Fri, Nov 29, 2013 at 11:34 AM, Adam Jacob adam@opscode.com wrote:
Maybe wait_for rather than if? Also, going to need to control timeout for the wait to avoid deadlocks.

On Nov 29, 2013 11:27 AM, “Daneel Yaitskov” rtfm.rtfm.rtfm@gmail.com wrote:
Hi,

What do you think about another attribute for the execute resource?
It’s wait or while.

Some processes as virsh start is async.
Using second execute resource is not short.

Example:

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
end

execute “while virsh domstate #{ name } | grep -q running ; do : ; done”

but with new attribute it could be

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
wait_if "virsh domstate #{ name } | grep -q running"
end


Daneel S. Yaitskov


#5

I think I like the idea of a block/wait resource more.

Adam

On Fri, Nov 29, 2013 at 11:43 AM, Noah Kantrowitz noah@coderanger.netwrote:

Whats the reason for this being part of the resource instead of its own
resource that just blocks the converge until the condition passes, or an
action on the resource (a la
https://github.com/balanced-cookbooks/jenkins/blob/master/libraries/jenkins.rb#L174-L186
)?

–Noah

On Nov 29, 2013, at 2:40 PM, Jordan Dea-Mattson jdm-lists@dea-mattson.com
wrote:

Yes, wait_for is the way to go.

We need to have a back off with a timeout.

Something like:
wait_for foo for N_SECONDS with N checks

Based on the timeout and the number of checks, an exponential back off
will be run.

On Fri, Nov 29, 2013 at 11:34 AM, Adam Jacob adam@opscode.com wrote:
Maybe wait_for rather than if? Also, going to need to control timeout
for the wait to avoid deadlocks.

On Nov 29, 2013 11:27 AM, “Daneel Yaitskov” rtfm.rtfm.rtfm@gmail.com
wrote:
Hi,

What do you think about another attribute for the execute resource?
It’s wait or while.

Some processes as virsh start is async.
Using second execute resource is not short.

Example:

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
end

execute “while virsh domstate #{ name } | grep -q running ; do : ; done”

but with new attribute it could be

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
wait_if "virsh domstate #{ name } | grep -q running"
end


Daneel S. Yaitskov


Opscode, Inc.
Adam Jacob, Chief Dev Officer
T: (206) 619-7151 E: adam@opscode.com


#6

Yeah, that seems to cover the general case best, though for LWRPs and other composed resources I would still vote for it to be a best practice to wrap that in an action :slight_smile:

–Noah

On Nov 29, 2013, at 2:55 PM, Adam Jacob adam@opscode.com wrote:

I think I like the idea of a block/wait resource more.

Adam

On Fri, Nov 29, 2013 at 11:43 AM, Noah Kantrowitz noah@coderanger.net wrote:
Whats the reason for this being part of the resource instead of its own resource that just blocks the converge until the condition passes, or an action on the resource (a la https://github.com/balanced-cookbooks/jenkins/blob/master/libraries/jenkins.rb#L174-L186)?

–Noah

On Nov 29, 2013, at 2:40 PM, Jordan Dea-Mattson jdm-lists@dea-mattson.com wrote:

Yes, wait_for is the way to go.

We need to have a back off with a timeout.

Something like:
wait_for foo for N_SECONDS with N checks

Based on the timeout and the number of checks, an exponential back off will be run.

On Fri, Nov 29, 2013 at 11:34 AM, Adam Jacob adam@opscode.com wrote:
Maybe wait_for rather than if? Also, going to need to control timeout for the wait to avoid deadlocks.

On Nov 29, 2013 11:27 AM, “Daneel Yaitskov” rtfm.rtfm.rtfm@gmail.com wrote:
Hi,

What do you think about another attribute for the execute resource?
It’s wait or while.

Some processes as virsh start is async.
Using second execute resource is not short.

Example:

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
end

execute “while virsh domstate #{ name } | grep -q running ; do : ; done”

but with new attribute it could be

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
wait_if "virsh domstate #{ name } | grep -q running"
end


Daneel S. Yaitskov


Opscode, Inc.
Adam Jacob, Chief Dev Officer
T: (206) 619-7151 E: adam@opscode.com


#7

I’m not good at English. I used analogy with not_if.
Execute resource already have timeout attribute.

On Fri, Nov 29, 2013 at 11:34 PM, Adam Jacob adam@opscode.com wrote:

Maybe wait_for rather than if? Also, going to need to control timeout for
the wait to avoid deadlocks.
On Nov 29, 2013 11:27 AM, “Daneel Yaitskov” rtfm.rtfm.rtfm@gmail.com
wrote:

Hi,

What do you think about another attribute for the execute resource?
It’s wait or while.

Some processes as virsh start is async.
Using second execute resource is not short.

Example:

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
end

execute “while virsh domstate #{ name } | grep -q running ; do : ; done”

but with new attribute it could be

execute “virsh shutdown #{ name }” do
only_if "virsh domstate #{ name } | grep -c running"
wait_if "virsh domstate #{ name } | grep -q running"
end


Daneel S. Yaitskov


Daneel S. Yaitskov