It looks like the root cause (for RBD) is in the test's cleanup resources step, it's not scheduling waits for volume status prior to issuing the next command. It schedules client.delete_volume , which just checks for 202 response code:
I suppose these operations are not dependent in the default backend, but for RBD there is enough delay to cause problems. The snapshot from which the second volume was created is deleted before the new volume completes - which fails. And then nova attempts to delete the original volume, which fails because a snapshot exists.
It seems to me that properly scheduling the waits in this test is the right way to go, rather than introducing retries in the driver.
It looks like the root cause (for RBD) is in the test's cleanup resources step, it's not scheduling waits for volume status prior to issuing the next command. It schedules client. delete_ volume , which just checks for 202 response code:
https:/ /git.openstack. org/cgit/ openstack/ tempest/ tree/tempest/ services/ volume/ json/volumes_ client. py#n94 /git.openstack. org/cgit/ openstack/ tempest/ tree/tempest/ thirdparty/ boto/test_ ec2_volumes. py#n67
https:/
I suppose these operations are not dependent in the default backend, but for RBD there is enough delay to cause problems. The snapshot from which the second volume was created is deleted before the new volume completes - which fails. And then nova attempts to delete the original volume, which fails because a snapshot exists.
It seems to me that properly scheduling the waits in this test is the right way to go, rather than introducing retries in the driver.