yahoo-eng-team team mailing list archive

[OpenStack Infra <2106463@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/948200
Committed: https://opendev.org/openstack/neutron/commit/39d95a14e2e3a067a1bc84dfd190e095e75db9e0
Submitter: "Zuul (22348)"
Branch:    master

commit 39d95a14e2e3a067a1bc84dfd190e095e75db9e0
Author: Rodolfo Alonso Hernandez <ralonsoh@xxxxxxxxxx>
Date:   Thu Apr 24 22:33:16 2025 +0000

    Initialize the network segment ranges only in first WSGI worker
    
    The implementation done in [1] does not fully work across WSGi workers.
    The method ``NetworkSegmentRange.new_default`` tries to first check if
    the default segment range for a specific driver (VLAN, tunnelled) is
    present. However, as seen in production environments, this method is
    not multiprocess safe.
    
    Instead, this patch is limiting the execution of the network segment
    ranges initialization to the first WSGI worker (there must be at least
    one worker).
    
    This patch also wraps the VLAN and tunnelled drivers initialization
    inside a database transaction context. All the operations executed in
    this method (register clean-up, new default registers creation and
    ranges sync) are done in one single database transaction, that ensures
    its isolation and integrity.
    
    NOTE: The same initialization method, when called, removes the
    duplicated registers created by [1] in first place. A Neutron API update
    and restart will fix the database ``network_segment_ranges`` registers.
    
    NOTE: The ranges class variable (``_TunnelTypeDriverBase.tunnel_ranges``
    or ``VlanTypeDriver.network_vlan_ranges``) stores initially the
    configured segment ranges (static configuration file). If the network
    segment range plugin is loaded, it will store the segment ranges from
    the database. But this variable should not be public; instead of this,
    the method ``get_network_segment_ranges`` provides the needed class API
    to retrieve this information.
    
    [1]https://review.opendev.org/c/openstack/neutron/+/938319
    
    Closes-Bug: #2106463
    Change-Id: Ibc42f900214e1f7631e266bccd083a2ef4111585


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

Title:
  network segment range initialization not updated

Status in neutron:
  Fix Released

Bug description:
  The fix https://review.opendev.org/c/openstack/neutron/+/938319 was
  trying to use the created_at time to 'lock' the existing segment range
  in DB. But it did not cover the situation that the ml2_conf.ini
  changes the vlan_range. So, the vlan range will be inconsistent
  between network segment range DB and ml2_conf.ini.

  Another case is that in our produciton environment we found that there are duplicated entry created in DB with completely same values:
  +--------------------------------------+------+---------+--------+------------+--------------+------------------+---------+---------+------------------+
  | id                                   | name | default | shared | project_id | network_type | physical_network | minimum | maximum | standard_attr_id |
  +--------------------------------------+------+---------+--------+------------+--------------+------------------+---------+---------+------------------+
  | 2c0097b7-d18c-4998-83e4-58e405a8ea11 |      |       1 |      1 | NULL       | vlan         | default          |     200 |    3969 |          1311788 |
  | a6046ac8-cfc2-4c7c-92a2-6f71d0acd9cc |      |       1 |      1 | NULL       | vlan         | default          |     200 |    3969 |          1311791 |
  +--------------------------------------+------+---------+--------+------------+--------------+------------------+---------+---------+------------------+

  So, the better solution is to add DB uniq constrait with keys of
  "network_type, physical_network, minimum, maximum", if duplicate entry
  found, just ignore it.

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