Comment 7 for bug 1881995

Revision history for this message
LIU Yulong (dragon889) wrote :

Accoring to your last comment log [1], we can see there is a snat destroy info:

2020-06-10 11:47:55.161 4887 DEBUG neutron.agent.l3.dvr_snat_ns [-] DVR: destroy snat ns: snat-b81dfaa6-21ba-4736-ad2c-2f6de8a297c4 delete /opt/stack/neutron/neutron/agent/l3/dvr_snat_ns.py:60

and then there is a list ns result which shows the qrouter-namespace is till there (but no snat-namepace):

2020-06-10 11:47:55.185 4900 DEBUG oslo.privsep.daemon [-] privsep: reply[140642348147824]: (4, ['qdhcp-367c9eaf-7acb-48c8-96f7-bb7da6e92e9d', 'qdhcp-780abcc2-7dbc-43d8-b242-bb5b3b8b22f8', 'fip-85fc5fbc-dbb4-4bc8-9fc5-6ee87e031b1b', 'qrouter-b81dfaa6-21ba-4736-ad2c-2f6de8a297c4', 'qdhcp-0ec11f4e-9391-4a68-a28c-bc9a20267219']) _call_back /usr/local/lib/python3.6/dist-packages/oslo_privsep/daemon.py:475

Based on the code path [2], the "destroy snat ns" is the last action of a router info deletation. But why the qrouter-namespace is still stand? This could indicate one thing is the router may still in the router info cache which will cause your next router_add_to_agent action do not hit the initialize function.

[1] https://launchpadlibrarian.net/483658618/neutron-l3-agent.log
[2] https://github.com/openstack/neutron/blob/master/neutron/agent/l3/dvr_edge_router.py#L236