It is available in Neutron lib since version 1.16 so pretty long time
now.
Also use segment api definition from neutron-lib, it's available
since version 1.19.0. The api definition from neutron-lib also
avoids circulary dependency b/w standard-attr-segment and segment
extension[1].
[1] https://review.opendev.org/c/openstack/neutron-lib/+/577866
Change-Id: I13699f8c494a15d8bb9e13f767f2725f7cab9f4f
Related-Bug: #1765008
This patch adds to legacy routers (no HA nor DVR) to be connected
to a router provider network segment through the gateway interface.
The router will be connected to one single segment of the RPN; that
means the router will have L2 connectivity to one single subnet.
The gateway router port will have an IP address on the subnet CIDR;
that will provide connectivity to the broadcast domain of this CIDR
(as usual, that doesn't change).
The router, in other scenarios, adds the other subnet CIDRs to the
router namespace routing table. That allows to SNAT any packet to
those CIDRs through the gateway port.
In the RPN case those routes are not added because there is no
broadcast connectivity with the other subnets. Any packet that needs
to reach these other subents, should go through the local segment
gateway IP address. This default route is added always into the
router namespace.
Closes-Bug: #1923592
Change-Id: Ib66b1d7b60eb0ac0a9e3dfd08aae29cb03abde34
With python 3.x, classes can use the metaclass= logic
to not require usage of the six library.
One step in removing all of six usage from neutron.
Change-Id: I2f815e412d9a96eb5faf2b3bb3a1e393a9db9309
When I'm trying to introduce a central sort-keys validation within
patch [1] to `get_sorts` method in `neutron.api.api_common` module,
I get blocked by some resource schemas and test cases. After reading
neutron API docs and some inspection, I believe there exists uses of
improper sort keys in test cases and some resource schemes need to
keep aligned with offical documents.
* Schemas of resource SecurityGroups/SG Rules/Segments don't provide
`is_sort_key` flag for their sort key properties claimed in offical
docs as neutron-lib does. See [2] for more details.
* Test cases of resource NetworkSegmentRange use unsupported sort keys,
e.g: physical_network. Replace it with `name` property. See [2] for more
details.
[1] https://review.opendev.org/#/c/653903/
[2] https://developer.openstack.org/api-ref/network/v2/index.html
Change-Id: I45a51736e4075e3dbc16827486869d70b659622d
Enforce validation on filter parameters on list requests.
If an API request contains an unknown or unsupported parameter,
the server will return a 400 response instead of silently ignoring
the invalid input.
In resource attributes map, all filter parameters are annotated by
the ``is_filter`` keyword. Attributes with is_filter set to True
are candidates for validation.
Enabling filter validation requires support from core plugin and
all service plugins so each plugin need to indicate if it supports
the validation by setting ``__filter_validation_support`` to True.
If this field is not set, the default is False and validation is
turned off. Right now, the ML2 plugin and all the in-tree service
plugin support filter validation. Out-of-tree plugins will have
filter validation disabled by default.
An API extension is introduced to allow API users to discover this
new API behavior. This feature can be disabled by cloud operators
if they choose to do that. If it is disabled, the extension won't
be presented.
Depends-On: Ic3ab5b3ffdc378d570678b9c967cb42b0c7a8a9b
Depends-On: I4397df1c35463a8b532afdc9c5d28b37224a37b4
Depends-On: I3f2e6e861adaeef81a1a5819a57b28f5c6281d80
Depends-On: I1189bc9a50308df5c7e18c329f3a1262c90b9e12
Depends-On: I057cd917628c77dd20c0ff7747936c3fec7b4844
Depends-On: I0b24a304cc3466a2c05426cdbb6f9d99f1797edd
Change-Id: I21bf8a752813802822fd9966dda6ab3b6c4abfdc
Partial-Bug: #1749820
With the work done in [1], [2] and [3], we should be able to normalize
the description for segments by relying on that from the
standardattrdescription description.
This patch removes the 'description' from the segment extension's
attribute map as well as adds the standard attribute description and
shim extension in [1] as required extensions to ensure the description
is in fact added. Also the UTs are updated to inject the std attr
description into the segment API attributes for testing and no longer
test that description can be None (not supported with std attr
description).
Additional work is needed to close up the partial bug herein:
- Updating the segment API def/ref in neutron-lib.
- Consuming the former in neutron so that the segment extension uses
the API from neutron-lib.
[1] https://review.openstack.org/#/c/562320/
[2] https://review.openstack.org/#/c/558318/
[3] https://review.openstack.org/#/c/562345/
Change-Id: I693222b7041f4f6f7f6a1096a22727a66364636a
Partial-Bug: 1757513
It looks the sorting and pagination are natively supported in
segment db layer but the segment controller doesn't mark these
features as supported. This patch fixes it.
Change-Id: I325396bb0256196ee6c6fc42cc812a0c75ae3827
Closes-Bug: #1763161
Standard attributes (i.e. revision_number, created_at, updated_at)
are missing in the segment resource. This is because the controller
doesn't process extensions on rendering the response. This patch
fixes it. In particular, this patch does the following:
* Process extensions when making the segment dict. This allows
other extensions to add attributes to segment response.
* Make segment extension implement update_attributes_map.
Tempest test: https://review.openstack.org/#/c/558609/
APIImpact update api reference of segments
Closes-Bug: #1760902
Change-Id: I3c93818002c2d7753454547231ba08544b6fa1c0
The segment extension's API definition was rehomed into neutron-lib with
commit I8b598c9aff2f0b28e5b11d3ab3570aeae2df1a4b
This patch consumes it by using lib's version of the module, removing
the rehomed code and updating the segment extension's test to mock
out standard_attr to ensure the description of segments isn't
overridden by the standardattrdescription extension.
NeutronLibImpact
Change-Id: Icea5981a5b920a30e159a0271052b9cc43236bc5
In reviews we usually check import grouping but it is boring.
By using flake8-import-order plugin, we can avoid this.
It enforces loose checking so it sounds good to use it.
This flake8 plugin is already used in tempest.
Note that flake8-import-order version is pinned to avoid unexpected
breakage of pep8 job.
Setup for unit tests of hacking rules is tweaked to disable
flake8-import-order checks. This extension assumes an actual file exists
and causes hacking rule unit tests.
Change-Id: Ib51bd97dc4394ef2b46d4dbb7fb36a9aa9f8fe3d
neutron-lib now contains the API definitions for neutron's core
resources. This patch removes the constant core resource and collection
variables and uses them from lib. Subsequent patches will consume the
actual core resource attribute definitions.
NeutronLibImpact
Change-Id: Ia9afdf620cd538b2aa420593277d6403a45c996b
Neutron-lib 1.1.0 is now out and contains the provider
network API definition (as per commit [1]). This patch
moves neutron references over to the neutron-lib
version.
NeutronLibImpact
- Consumers using the public constants within neutron's
providernet API extension must now use the values
from neutron-lib.
[1] cba0f9f0dd920b1f828c4bba3bd388d5b4eb9abf
Change-Id: I46390a159e93642901de87ea6604f2e7ffa03bad
Remove The following _MAX_LEN constants from
neutron/api/v2/attributes.py and use the corresponding DB field size
constants from neutron_lib.db.constants instead.
NAME_MAX_LEN --> NAME_FIELD_SIZE
TENANT_ID_MAX_LEN --> PROJECT_ID_FIELD_SIZE
DESCRIPTION_MAX_LEN --> DESCRIPTION_FIELD_SIZE
LONG_DESCRIPTION_MAX_LEN --> LONG_DESCRIPTION_FIELD_SIZE
DEVICE_ID_MAX_LEN --> DEVICE_ID_FIELD_SIZE
DEVICE_OWNER_MAX_LEN --> DEVICE_NAME_FIELD_SIZE
In alembic migration scripts, the raw numerical value is used.
For more information, see:
http://lists.openstack.org/pipermail/openstack-dev/2016-October/105789.html
NeutronLibImpact
Change-Id: I734890372584fe27e5d6ec38c0cad2de882ff11c
Adopt the class rehomed in https://review.openstack.org/389825
This change impacts subprojects that use ExtensionDescriptor from
neutron core. All subprojects should switch to using the class
directly from neutron-lib.
NeutronLibImpact
Change-Id: I0da90fb9d27a0a2008b60e56ed69bc9b9ae63c3e
It's written to but never read from!
Related-Bug: #1642426
This patch is required by neutron-lib adoption because it is part of
rehoming neutron/api/v2/attributes.py. All subprojects that reference
PLURALS must be patched to remove the reference.
NeutronLibImpact
Change-Id: Ifdf29b8fc4c824c0ee840c4f51593a5aa8a22127
Neutron Manager is loaded at the very startup of the neutron
server process and with it plugins are loaded and stored for
lookup purposes as their references are widely used across the
entire neutron codebase.
Rather than holding these references directly in NeutronManager
this patch refactors the code so that these references are held
by a plugin directory.
This allows subprojects and other parts of the Neutron codebase
to use the directory in lieu of the manager. The result is a
leaner, cleaner, and more decoupled code.
Usage pattern [1,2] can be translated to [3,4] respectively.
[1] manager.NeutronManager.get_service_plugins()[FOO]
[2] manager.NeutronManager.get_plugin()
[3] directory.get_plugin(FOO)
[4] directory.get_plugin()
The more entangled part is in the neutron unit tests, where the
use of the manager can be simplified as mocking is typically
replaced by a call to the directory add_plugin() method. This is
safe as each test case gets its own copy of the plugin directory.
That said, unit tests that look more like API tests and that rely on
the entire plugin machinery, need some tweaking to avoid stumbling
into plugin loading failures.
Due to the massive use of the manager, deprecation warnings are
considered impractical as they cause logs to bloat out of proportion.
Follow-up patches that show how to adopt the directory in neutron
subprojects are tagged with topic:plugin-directory.
NeutronLibImpact
Partially-implements: blueprint neutron-lib
Change-Id: I7331e914234c5f0b7abe836604fdd7e4067551cf
This patch adds the name and description column to the
networksegments table.
Change-Id: I7edc224e25e604dfd7613b945a4ca16d9e385760
Partially-Implements: blueprint routed-networks
This reverts commit b35d7fa3cb.
Patchset set is reverted after deciding Nova can get the segment_id
from the subnet associated to the port
Change-Id: Idf4ba107bf6e1427c82ab5b6a5cea0dba9264699
In this patchset, attribute 'ipam_segment_id' is added to ports to
contain the id of the segment where the port is bound in the case of a
routed network. This new attribute will be used by the Nova scheduler
to place an instance using the port in a host bound to the segment
Change-Id: Ide13a7c53c5f4a33894f459c38924830ba583f98
Partially-Implements: blueprint routed-networks
Any service plugin that implements the get_plugin_type method should
make it a classmethod. It should not need to be instantiated to
retrieve the simple constant it returns in every case.
Change-Id: Ia3a1237a5e07169ebc9378b1cd4188085e20d71c
Closes-Bug: #1590117
I hit this circular import which made it so that I couldn't import the
extension from db.py within the service plugin because the extension
imports the plugin. This seems backwards to me. The extension is the
interface and should pretty much stand alone shouldn't it? The
service plugin is the implementation and should be free to import it
at will.
This patch fixes the circular import issue.
Change-Id: I3b84496bf65578b02b43bbffb227db9bb9879288
Partially-implements: bp/routed-networks
Remove warning:
neutron.api.v2.attributes.convert_to_int()' has moved to
'neutron_lib.api.converters.convert_to_int()' in version
'mitaka' and will be removed in version 'ocata': moved to
neutron_lib
Change-Id: I0f6622b685a6b9ab030a13113badbefb729be013
Closes-bug: #1582541
Remove the deprecated warnings from unit tests. That is:
neutron/extensions/segment.py:51: DeprecationWarning: ATTR_NOT_SPECIFIED
in version 'mitaka' and will be removed in version 'newton': moved to
neutron_lib.constants
TrivialFix
Change-Id: Ie78f9b2be2b6c4d624964bfe268cb132403cef3a
Closes-bug: #1579967
This patch enables CRUD on Segments by defining a new entity called
'Segment' with an extension definition and some DB code to read the
existing segments DB. A basic framework for create, update, and
delete are provided.
For now, this is just the basic boiler-plate but I've got to start
somewhere. It is implemented as a service plugin that is disabled by
default because it has not been fully tested with any plugin.
Follow-on patches will implement support for this new extension in
ML2 and OVN at least.
Change-Id: Ifc370fdd38f9a5b296334635fa85bd93d270b910
Partially-Implements: blueprint routed-networks
Slawek Kaplonski