yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #83038
[Bug 1884527] [NEW] Related dvr routers aren't created on compute nodes
Public bug reported:
We observed in our d/s CI that scenario test test_connectivity_through_2_routers is failing for us in topology with 3 controllers and 2 compute nodes.
The reason why it was failing is that related routers wasn't created on compute nodes properly. Only routers to which VMs on host were connected were created.
After investigation I found out that this regression was caused by patch https://github.com/openstack/neutron/commit/48ea7da6c52ee14f0e9cc244fbc834283a8e74a7 because in some cases when "related router" is updated on L3 agent, it calls get_routers() in https://github.com/openstack/neutron/blob/390c4ac55f3ea883882412afdc1b921c4c3614e1/neutron/agent/l3/agent.py#L702 and that method on server side is looking if requested router is scheduled to the L3 agent or not and is also looking for routers related to the routers on the host. But isn't looking for routers related to the requested one as it is already "related" router.
So when L3 agent is already processing related router and will ask server about details of this router, it will not get it as this router isn't scheduled to that compute node (it's only related to other dvr router scheduled to the host).
** Affects: neutron
Importance: Medium
Assignee: Slawek Kaplonski (slaweq)
Status: Confirmed
** Tags: l3-dvr-backlog
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1884527
Title:
Related dvr routers aren't created on compute nodes
Status in neutron:
Confirmed
Bug description:
We observed in our d/s CI that scenario test test_connectivity_through_2_routers is failing for us in topology with 3 controllers and 2 compute nodes.
The reason why it was failing is that related routers wasn't created on compute nodes properly. Only routers to which VMs on host were connected were created.
After investigation I found out that this regression was caused by patch https://github.com/openstack/neutron/commit/48ea7da6c52ee14f0e9cc244fbc834283a8e74a7 because in some cases when "related router" is updated on L3 agent, it calls get_routers() in https://github.com/openstack/neutron/blob/390c4ac55f3ea883882412afdc1b921c4c3614e1/neutron/agent/l3/agent.py#L702 and that method on server side is looking if requested router is scheduled to the L3 agent or not and is also looking for routers related to the routers on the host. But isn't looking for routers related to the requested one as it is already "related" router.
So when L3 agent is already processing related router and will ask server about details of this router, it will not get it as this router isn't scheduled to that compute node (it's only related to other dvr router scheduled to the host).
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1884527/+subscriptions
Follow ups