4f79cb3932
Historically, we did not have a prohibition upon removing a VIF entry stored in the extra field, however the VIF attachment/detachment feature resulted in a task being created which by default attempts to pull a reservation lock unless explicitly shared. This is problematic as part of the process of undeploying a node as exclusive locks are generated. Presently, if any of those locked tasks run long, such as a new image being required or for some crazy reason, the BMC power request hangs for a few minutes, the VIF record may be orphaned and never removed, as the expectation is that nova deletes the VIF record from ironic. This allows the VIF record to be removed when a node is no longer in active use and possibly subject to a lock being held for a long period of time, such as when setting up for CLEANING. Additionally, this patch moves the actual VIF record deletion until after the detachment action in the event that it fails. This allows for the state in ironic to be consistent instead of the record being removed before the detachment occurs. Change-Id: Ib7544e43a2b26441d4f562b584bbc7fee6a11fea Closes-Bug: #1743652
9 lines
383 B
YAML
9 lines
383 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Addresses a condition where the Compute Service may have been unable to
|
|
remove VIF attachment records while a baremetal node is being unprovisiond. This
|
|
condition resulted in VIF records being orphaned, blocking future
|
|
deployments without manual intervention.
|
|
See `bug 1743652 <https://bugs.launchpad.net/ironic/+bug/1743652>`_ for more details.
|