]> review.fuel-infra Code Review - openstack-build/cinder-build.git/commit
long flashcopy operation may block volume service
authorAlan Jiang <ajiang@us.ibm.com>
Thu, 3 Oct 2013 22:03:09 +0000 (17:03 -0500)
committerAvishay Traeger <avishay@il.ibm.com>
Wed, 9 Oct 2013 17:50:28 +0000 (20:50 +0300)
commit7aa4f65a8c17aa037deff0f5b534ed694c17e62a
tree4a87a82ecd54a9eede2bb6c8f5aa65e2cb239a17
parentb00e307d7067e4b9cc86739291668be5b518badf
long flashcopy operation may block volume service

Storwize family uses flashcopy for snapshot or volume clone. The
volume delete has to wait until flashcopy finishes or errors out.
The _delete_vdisk() will poll volume FlashCopy status in a loop.
This may block volume serivce heartheat since it is in the same
. The solution is to use openstack FixedIntervalLoopingCall
to run the FlashCopy status poll in a timer thread.

The cinder volume mananger will resume delete operation for those
volumes that are in the deleting state during volume service startup.
Since Storwize volume delete may wait for a long time, this can cause
volume service to have long delay before it becomes available.
A greenpool is used to offload those volume delete operations.

Change-Id: Ie01a441a327e1e318fa8da0040ae130731b7a686
Closes-Bug: #1203152
cinder/tests/test_storwize_svc.py
cinder/volume/drivers/storwize_svc.py
cinder/volume/manager.py
etc/cinder/cinder.conf.sample