fa78b58010
The port delete events are not synchronized with network rpc events. This creates a condition which makes it possible for a port delete event to be processed just before a previously started network query completes. The problematic order of operations is as follows: 1) a network is scheduled to an agent; a network rpc is sent to the agent 2) the agent queries the network data from the server 3) while that query is in progress a port on that network is deleted; a port rpc is sent to the agent 4) that port delete rpc is received before the network query rpc completes 5) the port delete results in no action because the port was not present on the agent 6) the network query finishes and adds the port to the cache (even though the port has already been deleted) 7) some time passes and a new port is configured with the same IP address as the port that was deleted in (3) 8) the dhcp host file is corrupted with 2 entries for the same IP address. 9) dhcp queries for the newest port is rejected because of the duplicate entry in the dhcp host file. The solution is to add the network_id to the port_delete_end rpc event so that the _net_lock(network_id) synchronization point can be acquired so that it is processed serially with other network related events. To ensure backwards compatibility with newer agents running against older servers the determination of which network_id value to use in the lock is handled using a utility that will fallback to the previous mode of operation whenever the network_id attribute is not present in the *_delete_end RPC events. That utility can be removed in the future when it is guaranteed that the network_id attribute will be present in RPC messages from the server. Closes-Bug: #1732456 Change-Id: I735f8b1c9248b12e5feb6cbe970cf67f321e6ebc Signed-off-by: Allain Legacy <allain.legacy@windriver.com> |
||
---|---|---|
.. | ||
__init__.py | ||
test_agent.py |