Boot volumes API race

[Nikola Đipanov]

When there is a race for a volume between 2 or more instances, it is possible for more than one to pass the API check. All of them will get scheduled as a result, and only one will actually successfully attach the volume, while others will go to ERROR.

This is not ideal since we can reserve the volume in the API, thus making it a bit more user friendly when there is a race (the user will be informed immediately instead of seeing an errored instance).

[Sean Dague (sdague)]

putting in wishlist as it's a UX enhancement.

[Matt Riedemann (mriedem)]

Related to bug 1427060?

[Nikola Đipanov (ndipanov)]

Matt - not really since this is related to booting an instance, but the symptoms and the cause are the same - we need to use the reserve_volume call instead.

[Andrea Rosa (andrea-rosa-m)]

is there a way to reproduce this issue?
I'd like to work on it and I was wondering how I can reproduce it.
thanks

[Nikola Đipanov (ndipanov)]

Hi - sorry if this wasn't clear from the descripition:

$ cinder create --display-name=testvol 1
$ for i in {1..2} do; nova boot --flavor 1 --image $IMG --block-device source=volume,dest=volume,id=$VOL testvm$i & done;

Observe both requests succeed at the API layer and only fail at the compute with a stacktrace.

[Markus Zoeller (markus_z) (mzoeller)]

The bp serias "generic resource pools" [1] should solve this (very old) issue.

References:
[1] https://github.com/openstack/nova-specs/blob/63db6163968f9e25c4b6cb121c21660092bd4d88/specs/newton/approved/generic-resource-pools.rst