When allocating a partially defined segment with VLAN type driver, any
physical network can be returned. The method will select randomly any
VLAN segment available, independently of the physnet configured order.
Change-Id: I4d344f5ca6673b70b69a03503ec0f267bf0cadf7
Closes-Bug: #1929190
If plugin "network_segment_range" is not enabled and a new segment
is required, if no segmentation ID is provided in the request, the
segmentation ID assigned is randomly retrieved from the non
allocated segmentation IDs.
The goal is to improve the concurrent network (and segment) creation.
If several segments are created in parallel, this random query
will return a different segmentation ID to each one, avoiding the
database retry request.
Closes-Bug: #1920923
Change-Id: Id3f71611a00e69c4f22340ca4d05d95e4373cf69
Since [1], the physical network VLAN ranges parser populates the
ranges for those entries without a defined range, allowing all
valid VLAN ranges ([1, 4094]).
Some VLAN driver tests, relying on the previous implementation,
considered that the physical network without a defined VLAN
range does not have segments to allocated (those segments
are created on the fly by
"SegmentTypeDriverallocate_fully_specified_segment).
Since [1], all physical network segments are stored in the
"ml2_vlan_allocations" table and set as non allocated.
This patch also reverts [2]. When the physical networks are defined
in "network_vlan_ranges", there is no distinction between tenant
and provided networks; the physical network segments are assigned
by the user. It is possible to create a provider network without
defining the segmentation ID, it will be provided by the Neutron
VLAN driver, if there are free segments for the required physical
network.
[1]https://review.opendev.org/c/openstack/neutron-lib/+/779515
[2]1376df7873c2ac77c256ab2fed928de41a2c1d58
Closes-Bug: #1919280
Related-Bug: #1918274
Related-Bug: #1649750
Change-Id: I191e020ddb97dcf8fb41139d35bfd699e125379b
Now that we are python3 only, we should move to using the built
in version of mock that supports all of our testing needs and
remove the dependency on the "mock" package.
This patch moves all references to "import mock" to
"from unittest import mock". It also cleans up some new line
inconsistency.
Fixed an inconsistency in the OVSBridge.deferred() definition
as it needs to also have an *args argument.
Fixed an issue where an l3-agent test was mocking
functools.partial, causing a python3.8 failure.
Unit tests only, removing from tests/base.py affects
functional tests which need additional work.
Change-Id: I40e8a8410840c3774c72ae1a8054574445d66ece
In order to reduce the number of elements retrieved from the DB, this
patch, before processing the VLAN allocations per physical network,
deleted those registers belonging to any unconfigured physical network.
The VLAN registers per physical network are deleted using a bulk delete
operation, to speed up the process.
Those missing VLAN registers per network are now created using a bulk
insert operation, available in the ORM. This bulk operation speeds up
the sync process.
Change-Id: I8568e2277e157754aaff87a059a40e34e6a43e2b
Partial-Bug: #1862178
In case when vlan network was created with segmentation_id=0 and without
physical_network given, it was passing validation of provider segment
and first available segmentation_id was choosen for network.
Problem was that in such case all available segmentation ids where
allocated and no other vlan network could be created later.
This patch fixes validation of segmentation_id when it is set to value 0.
Change-Id: Ic768deb84d544db832367f9a4b84a92729eee620
Closes-bug: #1840895
This patch makes necessary changes to ML2 type drivers and plugin
manager for network segment range extension support when it is loaded.
When the network segment range extension is not loaded, no impact to the
current flow.
When the extension is loaded,
- populating a range that is managed from the configuration file [1]_,
such as "VLAN IDs", "VXLAN VNI IDs", "GRE tunnel IDs",
"Geneve VNI IDs" to the network segment range DB table as a "default"
and "shared" entry to maintain backward compatibility;
- reloading the "default" segment ranges when Neutron server
starts/restarts;
- creating a set of "default" network segment ranges out of the
ML2-config-file-defined ranges [1]_ and the segment allocation
operations are always retrieving the information from the DB to have
the network segment ranges fully administered via API;
- when a tenant allocates a segment, it will first allocate from an
available segment range assigned to the tenant, and then a shared
range if no tenant specific allocation is possible.
[1] /etc/neutron/plugins/ml2/ml2_conf.ini
Co-authored-by: Allain Legacy <Allain.legacy@windriver.com>
Partially-implements: blueprint network-segment-range-management
Change-Id: I522940fc4d054f5eec1110eb2c424e32e8ae6bad
The neutron.db.api.context_manager already references neutron-lib's
context manager; so consumers of it are already using neutron-lib. This
patch switches neutron's references to the context_manager over to
use neutron-lib's directly rather than that in neutron.db.api.
NeutronLibImpact
Change-Id: I97120faeec73690592ed21a5ec3c6202f61e1429
A bulk of the public APIs that are part of neutron.plugins.common.utils
were rehomed into neutron-lib with [1] and the remaining with [2].
This patch consumes [1] by:
- Removing the rehomed code from neutron.
- Removing the UTs that are no longer applicable.
- Leaving the functions in [2][3] in neutron.plugins.common.utils until
we release [2][3] and can consume it at which point we should be able to
remove the utils module.
NeutronLibImpact
[1] Iabb155b5d2d0ec6104ebee5dd42cf292bdf3ec61
[2] I2c0e4ef03425ba0bb2651ae3e68d6c8cde7b8f90
[3] I73f5e8ad7a1a83392094db846d18964d811b8bb2
Change-Id: I1d63cbea463e92e1d2e053f8e1a564ed52cb84f8
neutron-lib contains a number of the plugin related constants from
neutron.plugins.common.constants. This patch consumes those constants
from neutron-lib and removes them from neutron. In addition the notion
of the dummy plugin service type is moved strictly into the test
package of neutron since it's not a real service plugin.
NeutronLibImpact
Change-Id: I767c626f3fe6159ab3abd6a7ae3cb9893b79bf66
Refactoring neutron ml2 config opts to be in neutron/conf/plugins/ml2.
This would allow centralization of all configuration options and
provides an easy way to import.
NeutronLibImpact
Change-Id: Ibc5a9ab268578c243ef13f7e0041bacd6c0c410b
Partial-Bug: #1563069
Needed-By: Id0a97dda7718f06e33b2d30ce01cdcb3e9a46f7d
This patch integrates the Oslo-Versioned Objects created for
VlanAllocation, VxlanAllocation, VxlanEndpoints, GreAllocation,
GreEndpoints, GeneveAllocation and GeneveEndpoints into the
code base.
Partially-Implements: blueprint adopt-oslo-versioned-objects-for-db
Change-Id: I0d592bae452876b24c28ca4cc4bf6392b5ab6493
Co-Authored-By: Victor Morales <victor.morales@intel.com>
The ml2 MechanismDriver is now in neutron-lib along with its associated
constants. This patch switches over to the lib versions of those, but
leaves a shim of the MechanismDriver that just ref's the driver from
lib. This shim allows our broad consumer base of the driver to switch
over at their leisure.
NeutronLibImpact
Change-Id: I99e3de6d933a1bb341394f85415fb07306a82a01
When an operator configured multiple network VLAN ranges, we
had no guarantee that we would actually allocate in the order
specified like we do with segmentation types. In *most* cases,
the natural database order would be that the returned available
segment IDs would come back in the order of the physnets because
the sync_allocations code inserted them in that order. So it
became something some deployments would rely on and operators
would get a surprise when suddenly an allocation would happen
from the later physnets while many VLANs were still available
in the first one.
This patch just strictly makes allocation attempts in the order
of the network_vlan_ranges so operators are always guaranteed that
the later physnets will not automatically be allocated from unless
the earlier physnets are exhausted.
Change-Id: I14ca9b7e1141199f3ec221184fbbe156f1f9e18b
Use reader and writer for db operations.
Partially-Implements blueprint: enginefacade-switch
Depends-On: Iba3520ac6cfb6b82b2013df9b8e1aee64b10a11c
Change-Id: I50be115ea69f805b48b02aebe4259ec2c839830e
This patch raises InvalidInput to users when they create provider net
without seg_id if ml2_vlan_ranges just sets the physical net name. This
must be more friendly.
Closes-Bug: #1649750
Change-Id: I9831d1a5b5764dcb8ee94641a3afc3991e56f8c2
We have a number of functions that expect to get session as one
of the arguments. Passing session is not correct and this prevents
of using new enginefacade which expects context to be passed and
session will be injected in current context.
NeutronLibImpact
Partially-Implements blueprint: enginefacade-switch
Change-Id: I68ac442f11a6698bc43210fae877ba3809b1c02d
This patch will relocate the VlanAllocation db model from
plugins/ml2/drivers to db/models and separate it from mixins for OVO
implementation.
Change-Id: Ib544b22c9e1acaf4025e8cdace694b2000a4da90
Partial-Bug: #1597913
Introduce the neutron-wide 'global_physnet_mtu' option that
references the underlying physical network MTU. This also
introduces a method in plugin.common.utils that all plugins
should use to retrieve it. This value should be used to
calculate the proper MTU for virtual network components.
This patch also deprecate the 'segment_mtu' option specific
to the ML2 plug-in and makes ML2 reference this new option.
Closes-Bug: #1542475
Closes-Bug: #1542108
Change-Id: I6ffc8973c9b8f46cc19922ff04fdd2d23646b878
This change moves plugin test modules to conform to the new rules on
unit test tree structure (see TESTING.rst).
Vendor plugin paths continue to be ignored, and unit test modules that
test features instead of modules are also ignored pending their
removal to the functional test tree.
Change-Id: I482c377ca72ffd58692ad84bd9692356513e4c98
Closes-Bug: #1440834
Rodolfo Alonso Hernandez