Johannes Kulik
2a51df2760
Instead of returning an HTTP 200 and a `volumeAttachment` object, attaching a volume to an instance returns HTTP 202 starting from API version 2.101. To keep the functionality for older API versions, we move the `_attach_volume()` method from n-api to n-conductor and either do a call or a cast depending on whether the API needs to return a value. n-conductor then handles reserving the block_device_mapping's device by calling n-compute before it starts the previously-already-async volume attachment. We have to move `_check_attach_and_reserve_volume` into compute utils, because it's getting called in both conductor and compute api (for the shelved offloaded attach). The new RPC method in the conductor needs a long timeout when used with API versions less than the new 2.101, because it waits for the call to `reserve_block_device_name()` in nova-compute which already needs a long timeout. Updating the functional tests' `post_server_volume()` and `_attach_volume()` to not return the attachment anymore is possible, as no test uses the returned values. Change-Id: I4d38c2679f0e88cca30055a9c8c45ba1dd6fb5ef Implements: blueprint async-volume-attachments Signed-off-by: Johannes Kulik <johannes.kulik@sap.com>
11 lines
533 B
YAML
11 lines
533 B
YAML
---
|
|
features:
|
|
- |
|
|
A new microversion has been added to allow fully-asynchronous attachment of
|
|
volumes to a server. Previously, calling ``POST
|
|
/servers/{server_id}/os-volume_attachments`` to attach a volume would
|
|
return HTTP 200 containing a ``volumeAttachment`` object, returning a
|
|
device name. With API version 2.101 this changes to HTTP 202. The reason
|
|
is, that the device name could not be assured by any of the current drivers
|
|
and reserving the device name could block the API thread for some time.
|