yahoo-eng-team team mailing list archive

[OpenStack Infra <1884527@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/737286
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=38286dbd2e35f1f94bf06b5f1cfa9227e5d402c6
Submitter: Zuul
Branch:    master

commit 38286dbd2e35f1f94bf06b5f1cfa9227e5d402c6
Author: Slawek Kaplonski <skaplons@xxxxxxxxxx>
Date:   Mon Jun 22 17:08:15 2020 +0200

    [DVR] Related routers should be included if are requested
    
    In case when related dvr router is configured by L3 agent, it is first
    added to the tasks queue and then processed as any other router hosted
    on the L3 agent.
    But if L3 agent will ask neutron server about details of such router,
    it wasn't returned back as this router wasn't really scheduled to the
    compute node which was asking for it. It was "only" related to some
    other router scheduled to this compute node. Because of that router's
    info wasn't found in reply from the neutron-server and L3 agent was
    removing it from the compute node.
    
    Now _get_router_ids_for_agent method from the l3_dvrscheduler_db module
    will check router serviceable ports for each dvr router hosted on the
    compute node and will then find all routers related to it. Thanks to
    that it will return routers which are on the compute node only because
    of other related routers scheduled to this host and such router will not
    be deleted anymore.
    
    Change-Id: I689d5135b7194475c846731d846ccf6b25b80b4a
    Closes-Bug: #1884527


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
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:
  Fix Released

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