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
Relocate "_delete_expired_default_network_segment_ranges" to avoid
code redundancy.
Now instead of searching all objects and deleting one by one,
"delete_objects" is used.
Trivial-Fix
Change-Id: I1753263cb15ce2988ac4ccae03b7395069f2c4e9
Fixed the queries to retrieve the segment ID allocations when service
plugin network_segment_range is enabled. With the previous
implementation, a project user was able to allocate a segment ID
belonging to other project segment range.
The solution implemented was discussed in [1]:
- A project user will retrieve segments from the project ranges.
- When depleted, the segment IDs will be retrieved from the shared
range, never using another project segment ID.
[1]http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012736.html
Change-Id: I953062d9ee8ee5ee9a9f07aff4a8222ac63ed525
Closes-Bug: #1863423
Reduces E128 warnings by ~260 to just ~900,
no way we're getting rid of all of them at once (or ever).
Files under neutron/tests still have a ton of E128 warnings.
Change-Id: I9137150ccf129bf443e33428267cd4bc9c323b54
Co-Authored-By: Akihiro Motoki <amotoki@gmail.com>
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
Today the neutron common exceptions already live in neutron-lib and are
shimmed from neutron. This patch removes the neutron.common.exceptions
module and changes neutron's imports over to use their respective
neutron-lib exception module instead.
NeutronLibImpact
Change-Id: I9704f20eb21da85d2cf024d83338b3d94593671e
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
The remainder of the neutron.plugins.common.utils were rehomed into
neutron-lib with [1][2]. This patch consumes them by using the functions
from neutron-lib, and removing the neutron.plugins.common.utils module
all together as it's fully rehomed now.
NeutronLibImpact
[1] https://review.openstack.org/#/c/560950/
[2] https://review.openstack.org/#/c/554546/
Change-Id: Ic0f7b37861f078ce8c5ee92d97e977b8d2b468ad
The ml2 plugin driver API was rehomed into neutron-lib with commit
Ifc829953ef4d5859c3475903965dc08aba42fd9c and the API was shimmed in
neutron with I86a10091b55d1123e8d16f16155e0312bb10e54c. This patch
consumes the ML2 driver api from neutron lib thereby removing the
driver_api module from neutron.
NeutronLibImpact
Change-Id: Ice49572e217eeaf820e48d40f2251d08766490b5
Since Pike log messages should not be translated.
This patch removes calls to i18n _LC, _LI, _LE, _LW from
logging logic throughout the code. Translators definition
from neutron._i18n is removed as well.
This patch also removes log translation verification from
ignore directive in tox.ini.
Change-Id: If9aa76fcf121c0e61a7c08088006c5873faee56e
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>
Use reader and writer for db operations.
Partially-Implements blueprint: enginefacade-switch
Depends-On: Iba3520ac6cfb6b82b2013df9b8e1aee64b10a11c
Change-Id: I50be115ea69f805b48b02aebe4259ec2c839830e
Change 68ac442f11a6698bc43210fae877ba3809b1c02d introduce refactor
and start passing context instead of session.
For those who still use old TypeDriver usage methods
* allocate_fully_specified_segment
* allocate_partially_specified_segment
can end up with error. Current change adds check for type of the
argument that has been passed.
Change-Id: I8c6e60408dcc0a83ac401585c7cf962a84af92bd
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
Obviously there could be physical networks with same MTU.
The patch sets unique_values to False when parsing physical_network_mtus
Unit test added.
Closes-Bug: #1567502
Change-Id: I46e5b5d3f7033a974fca40342af6dff7c71a9a4a
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
When networks are created rapidly, neutron-servers compete
for segmentation ids which creates too much contention and
may lead to inability to choose available id in hardcoded amount
of attempts (11)
Randomize tunnel id selection so that condition is not hit.
Change-Id: I7068f90fe4927e6e693f8a62cb704213b2da2920
Related-Bug: #1382064
Closes-Bug: #1454434
ML2 will check the config parameters for the MTU settings.
It will check the segment, path and physnet mtu settings.
Change-Id: I58b57e01ec9bcafd7cdcfbf03149e98c3a1291ed
Partially-Implements: blueprint mtu-selection-and-advertisement
Use oslo_db helper that will allow to restart the whole
transaction in case it needs a certain operation to be repeated.
This is a workaround for the REPEATABLE READ problem where
retrying logic will not work because queries inside a transation
will not see updates made by other transactions.
So, run every attempt in a separate transaction.
Change-Id: I68f9ae8019879725df58f5da2c83bb699a548255
Closes-Bug: #1382064
It's mostly a matter of changing imports to a new location.
Non-obvious changes needed:
* pass overwrite= argument to oslo_context since oslo.log reads context
from its thread local store and not local.store from incubator
* don't store context at local.store now that there is no code that
would consume it
* LOG.deprecated() -> versionutils.report_deprecated_feature()
* dropped LOG.audit check from hacking rule since now the method does
not exist
* WritableLogger is now located in oslo_log.loggers
Dropped log module from the tree. Also dropped local module that is now
of no use (and obsolete, as per oslo team).
Added versionutils back to openstack-common.conf since now we use the
module directly from neutron code and not just as a dependency of some
other oslo-incubator module.
Note: tempest tests are expected to be broken now, so instead of fixing
all the oslo.log related issues for the subtree in this patch, I only
added TODOs with directions for later fix.
Closes-Bug: #1425013
Change-Id: I310e059a815377579de6bb2aa204de168e72571e
Oslo project decided to move away from using oslo.* namespace for all their
libraries [1], so we should migrate to new import path.
This patch applies new paths for:
- oslo.config
- oslo.db
- oslo.i18n
- oslo.messaging
- oslo.middleware
- oslo.rootwrap
- oslo.serialization
- oslo.utils
Added hacking check to enforce new import paths for all oslo libraries.
Updated setup.cfg entry points.
We'll cleanup old imports from oslo-incubator modules on demand or
if/when oslo officially deprecates old namespace in one of the next
cycles.
[1]: https://blueprints.launchpad.net/oslo-incubator/+spec/drop-namespace-packages
Depends-On: https://review.openstack.org/#/c/147248/
Depends-On: https://review.openstack.org/#/c/152292/
Depends-On: https://review.openstack.org/#/c/147240/
Closes-Bug: #1409733
Change-Id: If0dce29a0980206ace9866112be529436194d47e
Mostly trivial import changes.
- oslo.i18n no longer provide install() method to inject _() into
globals(), so removed all calls to it;
- removed Babel from dependencies (it will now be grabbed by oslo.i18n);
- updated tox.ini to ignore import violations for oslo.i18n.
Change-Id: I6623d551f512fb7fe9bf35ee734ed6d4c6cbc287
All the existing LOG.info, LOG.warning, LOG.error and LOG.critical
messages should have _LI, _LW, _LE and _LC respectively.
Also, debug level log shouldn't be translated.
This patch set will cover the ml2 directory under neutron/plugins.
Partial-Bug: #1320867
Change-Id: I9d78d23bbc14e7c536c6ddf2dc4f52c67faeb667
The DB_MAX_RETRIES implies that a query will be
retried that many times. 'retry' means it happened
once before. In the current code, if DB_MAX_RETRIES
is set to 1, the query won't be retried at all.
If it's set to 0, the query won't even be run.
This constant should actually be called DB_MAX_ATTEMPTS
to indicate that the variable includes the first try.
Change-Id: I13f088ffa38c40db7fd297173e892b4ad5c7fadd
The commit b3202c3283 used:
LOG.debug("...%(key1)s...", key1=value1)
which is not supported, this change ues instead:
LOG.debug("...%(key1)s...", {"key1": value1})
Change-Id: I9bd63c27ca8acf89284399fda8cd74c82906113b
ML2 provider networks partial specs let admins choose some provider
network attributes and let neutron choose remaining attributes. This
change provides the implementation for VLAN provider networks.
In practice, for VLAN provider networks provider:physical_network
and provider:segmentation_id choices can be delegated to neutron,
in such case neutron will try to find a network in tenant network
pools which respects provided provider attributes.
DocImpact
Related to blueprint provider-network-partial-specs
Partial-Bug: #1330562
Change-Id: I2c52c71167edaa153b2e04681273e2f1be8d03aa
Rodolfo Alonso Hernandez