b8e4aba1ec
A partner performing some testing recognized a case where if a request is sent to the Ironic Conductor while it is in the process of starting, and the request makes it into be processed, yet latter the operation fails with errors such as NodeNotLocked exception. Notably they were able to reproduce this by requesting the attachment or detachment of a VIF at the same time as restarting the conductor. In part, this condition is due to to the conductor being restarted where the conductors table includes the node being restarted and the webserver has not possibly had a chance to observe that the conductor is in the process of restarting as the hash ring is still valid. In short - Incoming RPC requests can come in during the initialization window and as such we should not remove locks while the conductor could possibly already be receiving work. As such, we've added a ``prepare_host`` method which initializes the conductor database connection and removes the stale locks. Under normal operating conditions, the database client is reused. rhbz# 1847305 Change-Id: I8e759168f1dc81cdcf430f3e33be990731595ec3
10 lines
407 B
YAML
10 lines
407 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Fixes an issue where ``ironic-conductor`` initialization could return a
|
|
``NodeNotLocked`` error for requests requiring locks when the conductor
|
|
was starting. This was due to the conductor removing locks after
|
|
beginning accepting new work. The lock removal has been moved to after
|
|
the Database connectivity has been established but before the RPC bus
|
|
is initialized.
|