commit 7aa4f65a8c17aa037deff0f5b534ed694c17e62a
Author: Alan Jiang <email address hidden>
Date: Thu Oct 3 17:03:09 2013 -0500
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.
Reviewed: https:/ /review. openstack. org/49647 github. com/openstack/ cinder/ commit/ 7aa4f65a8c17aa0 37deff0f5b534ed 694c17e62a
Committed: http://
Submitter: Jenkins
Branch: master
commit 7aa4f65a8c17aa0 37deff0f5b534ed 694c17e62a
Author: Alan Jiang <email address hidden>
Date: Thu Oct 3 17:03:09 2013 -0500
long flashcopy operation may block volume service
Storwize family uses flashcopy for snapshot or volume clone. The opingCall
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 FixedIntervalLo
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: Ie01a441a327e1e 318fa8da0040ae1 30731b7a686
Closes-Bug: #1203152