@Miguel
The RPC handlers (e.g., port_update_end) are all wrapped with "_wait_if_syncing" (https://review.openstack.org/#/c/609463/10/neutron/agent/dhcp/agent.py@491).
When that initial "sync_state()" is running, it will acquire a write lock to block all operations for a global sync call (https://review.openstack.org/#/c/609463/10/neutron/agent/dhcp/agent.py@491). During this time, if a RPC message is sent to the DHCP agent, it will wait if any sync operations/writers are in progress due to the "_wait_if_syncing" decorator mentioned above. And it will start processing after the sync ("sync_state()") has completed.
So, IMO the corner case described by Slawek will not happen since the message received during that sync process will not be dropped and will be handled later.
@Miguel /review. openstack. org/#/c/ 609463/ 10/neutron/ agent/dhcp/ agent.py@ 491). /review. openstack. org/#/c/ 609463/ 10/neutron/ agent/dhcp/ agent.py@ 491). During this time, if a RPC message is sent to the DHCP agent, it will wait if any sync operations/writers are in progress due to the "_wait_if_syncing" decorator mentioned above. And it will start processing after the sync ("sync_state()") has completed.
The RPC handlers (e.g., port_update_end) are all wrapped with "_wait_if_syncing" (https:/
When that initial "sync_state()" is running, it will acquire a write lock to block all operations for a global sync call (https:/
So, IMO the corner case described by Slawek will not happen since the message received during that sync process will not be dropped and will be handled later.