3PAR driver common uses time.sleep

[Walt Boring]

hp_3par_common calls time.sleep()

It should be calling eventlet.greenthread.sleep() to make sure we don't block the volume manager.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/77245

[John Griffith (john-griffith)]

So I finally (with the help of some test code and talking through it with eharney and guitarzan) understand the misconception here and why some drivers (like the 3par driver) have issues here.

For the general case time.sleep only blocks the calling thread, NOT the entire process. So I couldn't figure out why everyone was so up in arms about time.sleep being in the code. So I tested it, convinced myself that I was correct etc. But then it was pointed out some drivers were failing/blocking all access when using time.sleep. It turns out "yeah" because a lot of those drivers put global sync-locks all over in their code. So now you're hosed.

Anyway, what you have here will work around your lock I believe. I'm still not certain this is the best way to do this. Eharney for example is working on his own lock decorator that actually uses the volume-id which seems to me like a MUCH better approach.

All of that being said, I don't see any harm in this so if it's how you want to address it fine by me.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/77245
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=b493dcce93418ed09f0e2b7e1dccc20270deb75c
Submitter: Jenkins
Branch: master

commit b493dcce93418ed09f0e2b7e1dccc20270deb75c
Author: Walter A. Boring IV <email address hidden>
Date: Fri Feb 28 11:02:19 2014 -0800

    change time.sleep to use loopingcall

    We don't want to block the volume manager from servicing
    requests. So this patch changes our use of time.sleep
    to use loopingcall wait, which uses eventlet greenthread
    sleep.

    Change-Id: I13a1e4932e24ff5f09e35b8baa7c0fd5410388b6
    Closes-Bug: #1286285