c895d3e6bc
mnaser reported a weird case where an instance was found in both cell0 (deleted there) and in cell1 (not deleted there but in error state from a failed build). It's unclear how this could happen besides some weird clustered rabbitmq issue where maybe the schedule and build request to conductor happens twice for the same instance and one picks a host and tries to build and the other fails during scheduling and is buried in cell0. To avoid a split brain situation like this, we add a sanity check in _bury_in_cell0 to make sure the instance mapping is not pointing at a cell when we go to update it to cell0. Similarly a check is added in the schedule_and_build_instances flow (the code is moved to a private method to make it easier to test). Worst case is this is unnecessary but doesn't hurt anything, best case is this helps avoid split brain clustered rabbit issues. Closes-Bug: #1775934 Change-Id: I335113f0ec59516cb337d34b6fc9078ea202130f (cherry picked from commit |
||
---|---|---|
.. | ||
tasks | ||
__init__.py | ||
api.py | ||
manager.py | ||
rpcapi.py |