9eb116b99c
When trying to attach a volume to an already running instance the nova-api requests the nova-compute service to create a BlockDeviceMapping. If the nova-api does not receive a response within `rpc_response_timeout` it will treat the request as failed and raise an exception. There are multiple cases where nova-compute actually already processed the request and just the reply did not reach the nova-api in time (see bug report). After the failed request the database will contain a BlockDeviceMapping entry for the volume + instance combination that will never be cleaned up again. This entry also causes the nova-api to reject all future attachments of this volume to this instance (as it assumes it is already attached). To work around this we check if a BlockDeviceMapping has already been created when we see a messaging timeout. If this is the case we can safely delete it as the compute node has already finished processing and we will no longer pick it up. This allows users to try the request again. A previous fix was abandoned but without a clear reason ([1]). [1]: https://review.opendev.org/c/openstack/nova/+/731804 Closes-Bug: 1960401 Change-Id: I17f4d7d2cb129c4ec1479cc4e5d723da75d3a527
9 lines
283 B
YAML
9 lines
283 B
YAML
---
|
|
fixes:
|
|
- |
|
|
The `bug 1960401`_ is fixed which can cause invalid `BlockDeviceMappings`
|
|
to accumulate in the database. This prevented the respective volumes from
|
|
being attached again to the instance.
|
|
|
|
.. _bug 1960401: https://bugs.launchpad.net/nova/+bug/1960401
|