3a8a7e3fc6
We check the microversion when creating a new-style volume attachment. If we use that API and create the volume attachment, we're going to store the attachment id on the related BlockDeviceMapping object. Code that's updating or deleting attachments for a BDM with the attachment_id field set assumes that 3.27 is already available since it was when the attachment was created, and therefore we don't need to check the version again which saves us an extra GET / call to Cinder. We also don't support rollbacks of the Cinder API, but if that did happen and we requested 3.27 and it wasn't available, Cinder would return a 406 error which would result in a compute fault. Part of blueprint cinder-new-attach-apis Change-Id: I727fce7bbd84bcf58d7f1f91377fda35e36cbc7a |
||
---|---|---|
.. | ||
__init__.py | ||
cinder.py |