← Back to team overview

yahoo-eng-team team mailing list archive

[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