Is the sleep routine necessary when using aws_ebs_volume?

[fletchowns]

I came across this blog post: http://clarkdave.net/2013/04/managing-ebs-volumes-with-chef/

After using the aws_ebs_volume LWRP there's a ruby_block to do a sleep loop until the device is ready. Is that a necessary step? If so, any reason not have it baked into the aws cookbook?

(I asked this on the mailing list but didn't get any nibbles so I thought I'd try here)

[miketheman]

I recently read about a "waiter" class inside the aws-sdk gem - see here for more: http://docs.aws.amazon.com/sdkforruby/api/#Waiters

This might be a better way to run things instead of inducing sleep.

[tas50]

This really needs to get rewritten to use the waiters in the sdk now. The sleep is entirely unnecessary at this point.

[iennae]

So I started to tackle this when I saw the waiters and discovered that the documentation was lacking about what some of the meaning behind the waiters meant for ebs_volumes. I asked to get more clarification as it seemed like maybe there wasn't sufficient waiters and got the following response:

"We definitely could improve the documentation story for waiters in general. One way is to look at the waiter source - if you're trying to wait on a volume being attached, it doesn't look like we have a waiter that is tailored to that exact question yet. Mainly because I'm not sure that "in-use" is exactly the same as "attached". For creation, http://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/EC2/Waiters/VolumeAvailable.html - unless "created but not available" is an acceptable state, in which case we don't have an existing waiter for this. One interesting alternative that is easier to do in V3 is that you can actually create your own waiter instance with a custom definition. So, you can tweak the acceptors and use that."

My question didn't get exactly answered with regards to mapping out the conditions, but it seems like to some degree the sleeps need to stick around for some of the actions (or the actions need to get refactored). Once we migrate to v3 of the sdk we get customizable waiters.