4795527284
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 (cherry picked from commit |
||
|---|---|---|
| .. | ||
| api | ||
| cmd | ||
| common | ||
| conductor | ||
| conf | ||
| db | ||
| dhcp | ||
| drivers | ||
| objects | ||
| __init__.py | ||
| policy_fixture.py | ||
| raid_constants.py | ||
| stubs.py | ||
| test_base.py | ||