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 <[email protected]> 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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
