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
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
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
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 jenkins/libraries/jenkins.rb at master · balanced-cookbooks/jenkins · GitHub)?
--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
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
jenkins/libraries/jenkins.rb at master · balanced-cookbooks/jenkins · GitHub
)?
--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
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 
--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 jenkins/libraries/jenkins.rb at master · balanced-cookbooks/jenkins · GitHub)?
--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
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