Neutron-LBaaS has now been retired and there will be no Train
release[1]. This patch removes neutron-lbaas references from
neutron.
[1] https://review.opendev.org/658494
Closes-Bug: #1833125
Change-Id: I0fe3fbaf4adf7fb104632fd94cd093e701e12289
Switch plugin name references over to use the constants from
neutron_lib.plugins.constants in prep for
I5cbe779b401e5214f414ab1c732867fdd4d75651
Change-Id: Id96c8926483c504823c81a66a958d5941e52246d
The constant LOG_API was rehomed into neutron-lib with commit
I208c976c3e7e43e27e1907ed196af8efccd73f22
This patch consumes it by removing the constant from neutron and
using lib's version of it instead.
NeutronLibImpact
Change-Id: I97b135730af9efaa3b32c99b415f89c8a254a782
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
This patch introduces the logging api definition and initial
implementation of LoggingApiPlugin. The api definition code will
be removed after [1] has been merged on neutron lib.
[1]https://review.openstack.org/#/c/415817/
Co-Authored-By: Yushiro FURUKAWA <y.furukawa_2@jp.fujitsu.com>
Partially-implements: blueprint security-group-logging
Related-Bug: #1468366
Change-Id: Iace31506502de25da9dce5fcfdbfe2c726bea27f
The well known service type constants are in
neutron_lib.plugins.constants, but for legacy reasons a few still exist
and are referenced from neutron_lib.constants that we'd like to remove.
This patch switches references over to neutron_lib's plugin constants.
Change-Id: I1861448cec303725b30cef8f42029f467f9e03a3
Make use of the L3 constants from neutron-lib
NeutronLibImpact
Partially-implements: blueprint neutron-lib
Change-Id: I141469aac6ea01f4d9c90d9f533e466db8dc5fcf
Make use of the constant defined in the neutron-lib project.
NeutronLibImpact
Change-Id: I46d48f731b557383d00c0abd5fd582a1c0fb78c1
Partially-implements: blueprint neutron-lib
The Neutron 'created_at'/'updated_at' fields on API resources
were inconsistent with other OpenStack projects because we did
not include timezone information. This patch addressed that
problem by adding the zulu time indicator onto the end of the
fields.
Because this could break clients expecting no timezone, this patch
also eliminates the 'timestamp_core' and 'timestamp_ext' extensions
and consolidates them into a new 'timestamp' extension. This makes
the change discoverable via the API.
This is assuming the current API development paradigm where
extensions can come and go depending on the deployment and the client
is expected to handle this by checking the loaded extensions.
Once we decide extensions are permanent, this type of change will
no longer be possible.
Even though this is being proposed late in the cycle, it is better
to get this change in before the release where we expose even more
resources with incorrectly formatted timestamps.
APIImpact
Closes-Bug: #1561200
Change-Id: I2ee2ed4c713d88345adc55b022feb95653eec663
This adds the logic to increment the revision numbers
for objects whenever there are changes and it exposes
the revision number via a field in the API.
This is handled with a new default service plugin that
subscribes to DB events and bumps revision numbers for
any objects that were modified.
It also handles the logic for bumping the revision number
of a parent in a relationship where the children aren't
top-level neutron objects that would be tracked individually.
This is accomplished with a 'revises_on_change' attribute
on the child models that the service plugin will use to
find the parent and bump its revision.
API tests are included to test the revision numbers
added to each standard attribute enabled object.
Partially-Implements: bp/push-notifications
Change-Id: I476d3e03c8ee763cc4be6d679fe9f501eb3a19b5
The IPv6 header is twice the size of the IPv4 header, 40 vs 20
bytes, but the tunnel overhead constants are static, only
accounting for an IPv4 header in all cases. In order to be
correct it needs to treat the tunnel overhead different from
the IP overhead at L3.
This required removing the 20 byte IP overhead from the tunnel
type overhead constants and creating a new option,
ml2.overlay_ip_version, in order for the server to know which
version will be used, since it calculates the MTU for the network.
A version mis-match will now cause a tunnel sync to fail on
the server.
Moved all MTU tests to a common location to remove duplication.
DocImpact
Change-Id: Ia2546c4c71ff48b9fe2817fbad22b1fbf85f325b
Closes-bug: #1584940
This enables the flavor plugin by default. Since it is a
plugin that only controls flavor listing and associations
there isn't much of a downside to always having it enabled.
If another core plugin implements the flavors extension, this
will conflict with it, but we should standardize on a data model
across plugins for flavors so it will be better to encourage them
use the integrated flavors service plugin.
This also enables the 'flavors' extension for the API tests to
exercise the flavors functionality.
Partially-Implements: bp/multi-l3-backends
Change-Id: I6f27eaa02d6248a7f1ae5e6e81d4a60638cc6b7e
This patch is intended to add api tests for network ip availability.
Right now only tests for list is added in later revisions tests for
show will also be added
Change-Id: I8c1568d097525c43576e516bd86d820c6b0a78fb
Currently, neutron core resources (like net, subnet, port and subnetpool)
do not save time-stamps upon their creation and updation. This
information can be critical for debugging purposes.
This patch introduces a new extension called "timestamp" extending existing
the neutron core resources to allow their creation and modification times
to be record. Now this patch add this resource schema and the functions which
listen db events to add timestamp fields.
APIImpact
DocImpact: Neutron core resources now contain 'timestamp' fields like
'created_at' and 'updated_at'
Change-Id: I24114b464403435d9c1e1e123d2bc2f37c8fc6ea
Partially-Implements: blueprint add-port-timestamp
Introduce a generic mechanism to allow the user to set tags
on Neutron resources. This patch adds the function for "network"
resource with tags.
APIImpact
DocImpact: allow users to set tags on network resources
Partial-Implements: blueprint add-tags-to-core-resources
Related-Bug: #1489291
Change-Id: I4d9e80d2c46d07fc22de8015eac4bd3dacf4c03a
Service plugins are a great way of adding functionality in a
cohesive way. Some plugins (e.g. network ip availability or
auto_allocate) extend the capabilities of the Neutron server
by being completely orthogonal to the core plugin, and yet may
be considered an integral part of functionality available in
any Neutron deployment. For this reason, it makes sense to
include them seamlessly in the service plugin loading process.
This patch, in particular, introduces the 'auto_allocate' service
plugin for default loading, as we'd want this feature to be enabled
for Nova to use irrespective of the chosen underlying core plugin.
The feature requires subnetpools, external_net and router, while
the first is part of the core, the others can be plugin specific
and they must be explicitly advertised. That said, they all are
features that any deployment can hardly live without.
DocImpact: The "get-me-a-network" feature simplifies the process
for launching an instance with basic network connectivity (via an
externally connected private tenant network).
Once leveraged by Nova, a tenant/admin is no longer required to
provision networking resources ahead of boot process in order to
successfully launch an instance.
Implements: blueprint get-me-a-network
Change-Id: Ia35e8a946bf0ac0bb085cde46b675d17b0bb2f51
More information about Geneve protocol can be found here:
https://tools.ietf.org/pdf/draft-gross-geneve-02.pdf
Following configuration variables were added:
[ml2_type_geneve]
vni_ranges - Comma-separated list of <vni_min>:<vni_max> tuples
enumerating ranges of Geneve VNI IDs that are
available for tenant network allocation
max_header_size - Geneve encapsulation header size is dynamic, this
value is used to calculate the maximum MTU for the driver
this is the sum of the sizes of the outer
ETH + IP + UDP + GENEVE header sizes
DocImpact
Change-Id: I8c29a1c1a7c79e02c26ac9e2ad2645d30dfbeefc
Closes-Bug: #1461069
Also applied the following fixes:
===
1. cleaned up some pylint failures that were not spotted before:
Module neutron.objects.qos.policy: Metaclass class method __new__ should
have 'mcs' as first argument
Module neutron.objects.qos.rule: Lambda may not be necessary
===
2. Revert "Introduce the AFTER_READ callback for ports and networks"
This reverts commit e3dba14241.
We don't use callbacks to extend resources anymore, instead relying on
ml2 extension drivers. No need for the patch to achieve QoS, and it also
breaks test_delete_subnet_with_callback that was added in master
recently.
===
3. updated requirements.txt and test-requirements.txt based on:
https://review.openstack.org/#/c/204398/
to avoid requirements gate checks failing due to incompatible
requirements comparing to global-requirements.txt
Change-Id: I744ab2d8327a428a5467f2d07d073a5f8c333520
This patch introduces API and DB plugin for flavor framework.
API adds Flavors and Service Profiles which are resources
available only for admins to operate.
This framework then should be leveraged by advanced services.
Included tempest API tests in neutron tree
Implements: blueprint neutron-flavor-framework
Change-Id: I99ba0ce520ae3d8696eca5c994777c7d5ba3d4b1
Co-Authored-By: Doug Wiegley <dougw@a10networks.com>
Co-Authored-By: Madhusudhan Kandadai <madhusudhan.kandadai@hp.com>
Get rid of COMMON_PREFIXES, as now the prefix is a service's declaritive property.
Change-Id: I3d306131df94188f75e69edb13d262721d10bee5
Depends-on: I0450d0b2bf409d470a3a87bfd96518939759a84e
Depends-on: Ia34695967cbbec0a1cf0884dad82e096de8539b8
Depends-on: Ib9517b772fe426eaf0809c439aa3ba0448c7abaa
This dictionary does not belong to the plugins directory as it captures
API business, but practically speaking it does not even deserve to exist
and can be removed altogether.
This is patch one in a series that aims at addressing this monkey business.
Change-Id: I95cd71dfc35e266f6f3cc5715ab8a0deb10058e7
We can derive the services from EXT_TO_SERVICE_MAPPING, therefore
there is no need for duplicating the service labels into ALLOWED_SERVICES.
Change-Id: If92e0ea3dea4480588141a2819ea4036c527c9bc
This patch introduces the QoS service plugin which implements
a stub of the API extension.
This is patch is a basic step to be able to create an experimental
job enabling this service so we can do api tests.
Change-Id: Ib583e98c232ca628ba2a4bd48527eb84584c6212
This patch introduces the QoS API extension, in a basic
form where we could, in combination with the service plugin
stub, start creating some experimental test jobs that install
the service plugin.
Please not that URL mapping is not fully according to spec,
neither it does include any testing. We need to work that out.
blueprint quantum-qos-api
Change-Id: I86e8048e2d9b84690dbede9a94cfc884985069c5
It is quite confusing to have values for network type in common.constants.py
instead of having in plugins.common.constants.py.
Currently, the plugins/common/constants.py consists network_type constants
like VLAN, VXLAN, GRE etc. but values for network type like ranges
are defined in common.constants.py which is not good, it is better to have
both things at the same place.
This patch set addresses the same.
Moved out few methods which are predominantly used in plugins
from common.utils.py to plugins.common.utils.py.
Removed constants which were used in neutron-fwaas from
plugins.common.constants.py: https://review.openstack.org/#/c/168709/
Closes-Bug: #1441043
Change-Id: Iecfb15c541ed5d3cce95ba48f072af7fa60ac6f1
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
- Minor neutron.conf fix from feature branch until config is moved
- Some extra constants for extension
- Jinja template entry in services.conf
Change-Id: I4a15d0ac422457d2286d4b24d9f5067047e81563
Partially-Implements: blueprint services-split
Co-Authored-By: Brandon Logan <brandon.logan@rackspace.com>
On installing only neutron-linuxbridge-agent package, the
dhcp cannot start successfully because of the imports from
ovs plugin. This change removes the explicit include of the
ovs plugin from ovs_lib.py. INVALID_OFPORT has been moved to
ovs_lib.py while VXLAN_UDP_PORT has moved to
plugins/common/constants.py. The imports for these 2 constants
in files which uses it has been corrected to new location.
Closes-Bug: #1271449
Change-Id: I6559cb43d1b10b4f926c453a103b12017b59f259
When DVR is enabled as a default option for creating routers, firewall
resources will need to have a new initial state, so that reconciliation
can be done once all L3 agents have processed the firewall rules.
The new state has been introduced to preserve API bw compatibility
with centralized routers.
Partial-bug: #1360351
Supports-blueprint: neutron-dvr-fwaas
Change-Id: I53122570dd3a2311eedb24ccd925bcdc9ad4f70c
DEVICE_NAME_MAX_LEN constant in neutron.common.constants replaces
and correct multiple constants defining linux interface maximum
length.
Closes-Bug: #1332571
Change-Id: I63f760a21e17dcd57b3685b1e71c913d2722e097
Refactor the functional tests a bit to add a common base class for agent
tests. This is needed an upcoming commit which adds a functional test
for VXLAN version checking.
Closes-Bug: #1301363
Change-Id: I438e401cbfb40e5557e5125f2a409bac5c1fd1c2
Looking at the lbaas code it's not very obvious that constants.ACTIVE_PENDING
is a list of statuses that contain statuses that are ACTIVE or
PENDING. This patch renames ACTIVE_PENDING to ACTIVE_PENDING_STATUSES so
it's obvious that this is a list and not just a string called ACTIVE_PENDING.
Closes-bug: #1295790
Change-Id: I7af96bcc6b145c6ab809c0b032ccb18baad9c98e
When agent requests loadbalancer logical config from server,
server returns only active pool members and health_monitors.
Need to make server return also members and monitors which are in pending states.
Also a small refactoring moving ACTIVE_PENDING set to common place
Change-Id: I8e10004f199f982b055da18ea7a0e5e4d11fa7fb
Closes-Bug: #1259965
This patch removes new definitions of common network type constants (TYPE_FLAT,
TYPE_LOCAL, etc.) and modifies uses of aforementioned constants to a common
place where constants are defined (neutron.plugins.common.constants). This
patch does not change values that are equal in value but different in name:
NETWORK_TYPE_FLAT vs TYPE_FLAT. A second changeset will be made to handle that
case.
Unit tests were modified as well when they referred to the constant.
Finally, the ovs agent code refers to the OVS plugin constants directly and
these had to be changed as well. A TODO flag was put in that file due to use
of another plugin specific constant.
Network types that were only defined in a single plugin, such as mellanox's
infiniband (IB) network type was not carried over to the common constants file.
Fixes-bug: #1196170
Change-Id: Ib6bfc8275496a24bf247946d177c734b62ae44bb
Implements blueprint ipsec-vpn-reference
This patch implements reference driver implementation for VPNaaS.
The driver uses openswan to manage vpn connections.
Future work: Support ikepolicy and ipsec update
Support service type framework
Intelligent updating of resources
This commit adds jinja2 for requirements.txt for
generating cofig file.
Change-Id: I8c5ed800a71ca014dc7bdbb6a57c4f8d18fa82e0
This a part of the blueprint bandwidth-router-label
This patch initiates the blueprint by adding base class
to associate labels and metering rules to tenant's routers.
Change-Id: Ia93b49d881e79c3291730cff7b80f26c56fedb48
implements:blueprint VPNaaS-Python-API
It provides the basic API and
DataModel for the "VPN As A
Service" feature that includes:
* VPNService
* IPsecSiteConnection
* IKEPolicy
* IPsecPolicy
Change-Id: I059d4db05118a4eecd388b8e8db0d714a8f9cb8f
Implements: blueprint quantum-fwaas
blueprint: quantum-fwaas-plugin
This is the first iteration of the FWaaS implementation and
is geared towards implementing the model that will be
required to at least address the reference implementation.
This iteration will not include implementation of the following
features:
* grouping or dynamic objects
* application/service objects
Change-Id: I57a62d6e9d3f1e6c4dd44cd5c745710a3d9e488e
This change renames everything to Neutron while providing backwards
compatible adjustments for Grizzly configuration files.
implements blueprint: remove-use-of-quantum
Change-Id: Ie7d07ba7c89857e13d4ddc8f0e9b68de020a3d19
Michael Johnson