yahoo-eng-team team mailing list archive

[OpenStack Infra <2006496@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/873107
Committed: https://opendev.org/openstack/neutron/commit/5250598c804a38c55ff78cfb457b73d1b3cd7e07
Submitter: "Zuul (22348)"
Branch:    master

commit 5250598c804a38c55ff78cfb457b73d1b3cd7e07
Author: Rodolfo Alonso Hernandez <ralonsoh@xxxxxxxxxx>
Date:   Wed Feb 8 13:14:19 2023 +0100

    Improve scheduling L3/DHCP agents, missing lower binding indexes
    
    This patch is covering an edge case that could happen when the number
    of DHCP agents ("dhcp_agents_per_network") or L3 agents
    ("max_l3_agents_per_router") has been reduced and there are more agents
    assigned than the current number. If the user removes any agent
    assignation from a L3 router or a DHCP agent, it is possible to remove
    first the lower binding assigned registers.
    
    Now the method ``get_vacant_binding_index`` calculates the number of
    agents bound and the number required. If a new one is needed, the
    method returns first the lower binding indexes not used.
    
    Closes-Bug: #2006496
    Change-Id: I25145c088ffdca47acfcb7add02b1a4a615e4612


** 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/2006496

Title:
  [L3-HA] "max_l3_agents_per_router" not honored when the redundancy is
  reduced

Status in neutron:
  Fix Released

Bug description:
  Related bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2166197

  NOTE: Config option "router_distributed" must be False.

  This issue is happening when initially we have a
  "max_l3_agents_per_router" number, we create a router and then we
  reduce the redundancy.

  For example, if "max_l3_agents_per_router=3" and we create a HA router. Neutron will create 3 instances of this router and will create the corresponding "routerl3agentbindings" registers. E.g.:
  MariaDB [ovs_neutron]> select * from routerl3agentbindings;
  +--------------------------------------+--------------------------------------+---------------+
  | router_id                            | l3_agent_id                          | binding_index |
  +--------------------------------------+--------------------------------------+---------------+
  | f8d3fec5-4648-48e9-b546-94f2e135df77 | 5c54529e-1f4e-4332-9674-96a1d15a16b2 |             1 |
  | f8d3fec5-4648-48e9-b546-94f2e135df77 | 8112e03e-9191-495d-aea2-d2d7cd621767 |             2 |
  | f8d3fec5-4648-48e9-b546-94f2e135df77 | 850beebc-3144-4673-a4cc-142162dba436 |             3 |
  +--------------------------------------+--------------------------------------+---------------+

  
  Now we reduce the redundancy to "max_l3_agents_per_router=1". If we remove the agent assignation for those registers with "binding_index" different to 1, the next time the router is updated, the L3 scheduler will create a new assignation with "binding_index=1". When the router is updated (a subnet is added or removed, a FIP is assigned or removed, etc), the scheduler is called. This method [1] will determine what is the next index that needs to be created (that is used both for the DHCP scheduler and the L3 scheduler).

  In the given example, if the agents with "binding_index" different from 1 are removed, the vacant binding index method [1] will return 1:
    open_slots = sorted(list(all_indicies - set(binding_indices)))
    --> all_indicies = {1}
    --> binding_indices = {3}  # for example
    --> open_slots = {1}  # instead of an empty set(), as expected here.

  [1]https://github.com/openstack/neutron/blob/7c3d6c414d3c0f085cae94b6f2186c4415a9298b/neutron/scheduler/base_scheduler.py#L102-L107

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2006496/+subscriptions