yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #95955
[Bug 2106463] Re: network segment range initialization not updated
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
References