fea2d9091f
When a network is deleted, precommit handlers are notified prior to the deletion of the network from the database. One handler exists in the ML2 plugin - _network_delete_precommit_handler. This handler queries the database for the current state of the network and uses it to create a NetworkContext which it saves under context._mech_context. When the postcommit handler _network_delete_after_delete_handler is triggered later, it passess the saved context._mech_context to mechanism drivers. A problem can occur with provider networks since the segments service also registers a precommit handler - _delete_segments_for_network. Both precommit handlers use the default priority, so the order in which they are called is random, and determined by dict ordering. If the segment precommit handler executes first, it will delete the segments associated with the network. When the ML2 plugin precommit handler runs it then sees no segments for the network and sets the provider attributes of the network in the NetworkContext to None. A mechanism driver that is passed a NetworkContext without provider attributes in its delete_network_postcommit method will not have the information to perform the necessary actions. In the case of the networking-generic-switch mechanism driver where this was observed, this resulted in the driver ignoring the event, because the network did not look like a VLAN. This change uses a priority of zero for ML2 network delete precommit handler, to ensure they query the network and store the NetworkContext before the segments service has a chance to delete segments. A similar change has been made for subnets, both to keep the pattern consistent and avoid any similar issues. Change-Id: I6482223ed2a479de4f5ef4cef056c311c0281408 Closes-Bug: #1841967 Depends-On: https://review.opendev.org/680001 |
||
---|---|---|
.. | ||
notes | ||
source |