This patch implements the new network HA boolean field API extension.
This field is an input only parameter for POST operations (creation).
By default is "False". When enabled, the Neutron server will create
a ``ha_router_networks`` register in the same transaction of the
network creation.
If by any circumstance (a race condition, for example), another
``ha_router_networks`` exists in the same project, a
``DBDuplicateEntry`` exception will be raised and the transaction
will be rolled back.
Partial-Bug: #2016198
Change-Id: Ie42c13ecbe4abcad9229b71f6942e393fd0f2e4e
if we list floating ip and want to operate a port forwarding, we cannot
call the update 'port forwarding' api, because we don't know the port
forwarding id.
this patch adds the port forwarding returned contents: 'id' and
'internal_port_id' when list floatingip.
Closes-bug: #1971646
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/840584
Change-Id: Ie1d9169cd07547491144776311d77d49b483d5ae
The extension in neutron-lib was released in 1.29.0 so it is time to
use the extension from neutron-lib.
Change-Id: Id2bd872646feede7179affe8c7d124b4530afc9d
Related-Bug: #1811166
I avoided changing the pre-existing extraroute implementation to
also avoid any breakage of legacy behavior. Alternatively we can
refactor the extraroute code to better fit both APIs:
* the old: updates to the 'routes' attribute and
* the new: actions 'add_extraroutes' / 'remove_extraroutes'.
Change-Id: Ia78e0e02de4a42a056e3ff654d8b6976a4e52616
Closes-Bug: #1826396 (rfe)
Depends-On: https://review.opendev.org/679259
Related-Change: https://review.opendev.org/655680 (spec)
Enforce that a user updates the admin state of a router before modifying
the distributed state. The API currently allows setting admin state to
false concurrently with changing the distributed state.
This is fine for a transition of centralized->distributed, but the
distributed->centralized transition could leave other nodes configured
as distributed until an audit is performed.
Commit adds shim api extension which should be replaced by neutron-lib
shim extension once https://review.openstack.org/#/c/634509/ is merged.
New method 'is_admin_state_down_necessary' checks that shim extension
is loaded.
Set extension as standard by adding to _supported_extension_aliases in
neutron/services/l3_router/l3_router_plugin.py
Closes-Bug: #1811166
Co-Authored-By: Allain Legacy <allain.legacy@windriver.com>
Co-Authored-By: Enyinna Ochulor <enyinna.ochulor@intel.com>
Change-Id: Ie624aeb3f3aeb4db176d2ca0b22020208d4b408a
Signed-off-by: Matt Welch <matt.welch@intel.com>
The functionality within neutron.db.common_db_mixin is available via
neutron-lib APIs. This patch removes common_db_mixin and updates any
uses of it to use neutron-lib instead.
Depends-On: https://review.openstack.org/#/c/636159/
NeutronLibImpact
Change-Id: I2388f90b37abb09408809dda8c21da551bcd94bb
Today a number of classes define their supported_extension_aliases
using static strings rather than API definition ALIASes. This patch
switches them to use the ALIAS where applicable.
Change-Id: I716270c68a9fcd850c3c26de31bc13ea16def23d
Today a number of classes define their _supported_extension_aliases
using static strings rather than API definition ALIASes. This patch
switches them to use the ALIAS where applicable.
Change-Id: Id3be9ff7d84811c05793811306a13262fd3c0787
The neutron.common.rpc module has been in neutron-lib for awhile now and
neutron is shimmed to use neutron-lib already.
This patch removes neutron.common.rpc and switches the code over to use
neutron-lib's implementation where needed.
NeutronLibImpact
Change-Id: I733f07a8c4a2af071b3467bd710290eee11a4f4c
The _resource_extend module is already rehomed into neutron-lib and is
shimmed in neutron. This patch removes the module as no active
consumers are using it.
NeutronLibImpact
Change-Id: I1550075fa5fa2aa2f1a88ee7189d311a1fe78391
Some L3 ports can directly modify the IP address now,
but there are some types of device_owner, for instance
network:router_centralized_snat, should not allow to
change the IP address, otherwise it will increase L3
agent code complexity.
Since router public gateway port is related to the
external network, and this port can be used for some
service, like VPN. So after this patch we will only
allow the gateway port to update the IP address
directly, aka device_owner network:router_gateway.
The following l3 router ports will not be allowed to
directly update the IP address:
network:ha_router_replicated_interface
network:router_centralized_snat
network:router_ha_interface
network:router_interface
network:router_interface_distributed
Remove one unit test case since it will not occur in
neutron.
Change-Id: I2890a71abc82cb781b601afb879bdcca10e39257
Closes-Bug: #1796824
This patch enables to bind a QoS policy to the router gateway,
then in L3 agent side SNAT traffic for the VMs without floating
IPs can be limited under the policy bandwidth rules. This is
suit for all kinds of L3 routers: DVR, DVR with SNAT HA, L3 HA
and Legacy.
API update router gateway json:
{
router": {
"external_gateway_info": {
...
"qos_policy_id": "policy-uuid"
}
}
}
Depends-On: https://review.openstack.org/#/c/567497/
Partially-Implements blueprint: router-gateway-ip-qos
Closes-Bug: #1757044
Related-Bug: #1596611
Change-Id: I26e22bce7edd1f93b2ac0048b61b14f858938537
Add support for listing floating ip pools (subnets).
A new API resource ``floatingip-pools`` is introduced.
This API endpoint can return a list floating ip pools
which are essentially mappings between network UUIDs and
subnet CIDRs. Users can use this API to find out the pool
to create the floating IPs.
Related patches:
* neutron-lib: https://review.openstack.org/#/c/556674/
* tempest-plugin: https://review.openstack.org/#/c/562038/
APIImpact add floatingip pools api
Change-Id: Iaa995630645042520df67d95271e14f11ffcff8c
Partial-Bug: #1653932
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
The neutron.common.rpc.create_connection function is just a reference to
the Connection class constructor. This patch removes create_connection
and replaces all uses with Connection instead.
NeutronLibImpact
Change-Id: I2f4b24ba732be47fc9911be1e24406fb1ffe821e
The neutron.common.topics module was rehomed into neutron-lib with
commit Ie88b84949cbd55a4e7ad06341aab77b286cdc485
This patch consumes it by removing the rehomed module from neutron
and using the module from neutron-lib instead.
NeutronLibImpact
Change-Id: Ia4a4604c259ce862597de80c6deeb3d408bf0e95
Commit I81748aa0e48b1275df3e1ea41b1d36a117d0097d added the l3 extension
API definition to neutron-lib and commit
I2324a3a02789c798248cab41c278a2d9981d24be rehomed the l3 exceptions,
while Ifd79eb1a92853e49bd4ef028e7a7bd89811c6957 shims the l3
exceptions.
This patch consumes the l3 api def by:
- Removing the code from neutron that's now in lib.
- Using lib's version of the code where applicable.
- Tidying up the related unit tests as now that the l3 api def from lib
is used the necessary fixture is already setup in the parent chain when
setting up the unit test class.
NeutronLibImpact
Change-Id: If2e66e06b83e15ee2851ea2bc3b64ad366e675dd
Add qos_policy_id to floating IP, then the user could set/update
the binding QoS policy of a floating IP.
APIImpact: a new parameter qos_policy_id was added to floating IP
related API.
Partial-Bug: #1596611
Partially-Implements blueprint: floating-ip-rate-limit
Change-Id: I4efe9e49d268dffeb3df4de4ea1780152218633b
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
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
By registering functions directly we cut off the dependency of the
"resource extend" functions on the plugin. This is a step towards
the goal of removing the CommonDbMixin mixin class.
Also, we register all "resource extend" functions at plugin create
(in __new__) instead of in the class definition (which caused the
hooks to be registered on import). This ensures the "resource
extend" functions are only registered for the plugins/mixins that
are actually used.
Note that decorators are used to register "resource extend" methods,
similar to the callback receiver decorators.
Related-Blueprint: neutron-lib
Change-Id: I128cfda773d5f9597df9cd61261fdc05f2a174aa
A lot of clouds using the router service plugin don't configure for DVR,
but the service plugin still loads the extension, and exposes it via
API. Which will break if api consumers (admins with default policy.json)
attempt to create new style routers based on the information passed
through /extensions/ api.
This change introduces a new config option that allows to avoid loading
the extension. For complatibility sake, it requires an opt-in from ops
side to disable it, otherwise the extension is still loaded as before.
This is helpful for automation matters. It may also be useful when
preparing tempest.conf api_extensions=, when you could actually pass the
result of /extensions/ request into tempest and expect the test suite to
pass without yanking dvr off the list for non-dvr setups.
We could go further and try to check if the controller is configured
properly. That is complicated by the fact that f.e. such validation may
require talking to ml2 drivers, or even agents, which is not feasible
during api startup.
Change-Id: I84be9be93862fe71a2d5b5322d7ebd476c784163
Related-Bug: #1450067
Neutron lib now contains ServicePluginBase [1]. In accordance
with the discussion in [2], this patch:
- Removes ServicePluginBase from neutron and replaces all uses
with neutron-lib.
- Removes PluginInterface; the plugin interface for extensions
is ServicePluginBase; that's what's used by everyone today.
- Updates a few UTs, based on the above.
NB: A subsequent patch will address the WorkerSupportServiceMixin
so its untouched herein.
NeutronLibImpact
[1] I2b1131ac53e9bfeb42a92f9ef134be6ff4cfe5a3
[2] https://review.openstack.org/#/c/424151/
Change-Id: I1e8f2ee6a96df9ba07dae37f1a80e61ad20693cc
Move the model query hook registration and resource extend funcs
registration methods out of the CommonDbMixin class and make them
regular utility functions.
This is a step in refactoring the CommonDbMixin class.
Change-Id: Iec1bb7f7098c83640ae695fd7cf2f4736f414ad2
Make use of the L3 constants from neutron-lib
NeutronLibImpact
Partially-implements: blueprint neutron-lib
Change-Id: I141469aac6ea01f4d9c90d9f533e466db8dc5fcf
This adjusts the L3 scheduler framework to ask the L3 plugin if
a given router should be scheduled before scheduling it. To maintain
backwards compatibility, this new method is implemented to return True
in the base class.
The L3 plugin with flavor support overrides this to lookup the driver
associated with a router and check if the driver requires the L3
scheduling framework. This will allows the coexistence of flavors that
needs scheduling and flavors that don't.
Change-Id: I17a64c59eaf5d8605ff8ec2a29e491673be960e7
Implements: blueprint multi-l3-backends
After reboot(restart of l3 and l2 agents) of the node routers
can be processed by l3 agent before openvswitch agent sets up
appropriate ha ports. This change add notification for l3 agent
that ha port becomes ACTIVE and keepalived can be enabled.
Closes-bug: #1597461
Co-Authored-By: venkata anil <anilvenkata@redhat.com>
Change-Id: Iedad1ccae45005efaaa74d5571df04197757d07a
Agentless L3 plugins, such as used by networking-ovn, were required
to inherit from L3_NAT_db_mixin instead of L3_NAT_dbonly_mixin due
to an L3 NAT DB signature mismatch which was fixed by [1]. With [1]
fix, agentless L3 plugins would still implicitly pick up callbacks
intended for use by L3 agents. Such callbacks will fail unless the
L3 plugin inherits from L3_NAT_db_mixin. This patch supports
callbacks for L3 plugins without an agent. The callbacks
have been refactored and are now done implicitly during object
creation. As a result, the l3_db subscribe() method has been
deprecated.
[1] https://review.openstack.org/#/c/348558/
Change-Id: Id5dd012ffd274314f7d1b39a28525893e0675500
Partial-Bug: #1597898
This is the initial support for flavors and multiple service
providers with the built-in L3 service plugin.
This patch handles a few key components:
* Adds an optional flavor_id to the router data model
* Adds a new driver controller that performs the following tasks:
* Loads up the configured drivers and 4 default drivers representing
the current matrix of ha/dvr options (single node, ha, dvr, and ha+dvr)
* Associates every router with a driver based on ha/dvr attributes
or the flavor_id if specified
Note that the current drivers are very limited because they don't do anything.
All of the complex logic for the in-tree drivers is still tied up in the giant
mixin the service plugin inherits. Breaking that apart will be in follow-up
patches.
Partially-Implements: blueprint multi-l3-backends
Change-Id: Idce75bf0fc1375dcbbff9b9803fd2fe97d158cff
Tests are already present to validate that no regression happens here,
committed as part of Ib3709d15fd87b93285dadf78cce73ee37e8898e2
Change-Id: I4cdb1c4b8ee233d9d5bc78b0d3bd2ce28e725535
Related-Bug: #1566514
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
This reverts commit b1cdba1696
Original patch was reverted because it broke neutron plugin's
backward compatibility and needed more work.
This patch fixes that problems:
1) original behaviour of add_agent_status_check,
start_periodic_l3_agent_status_check and
start_periodic_dhcp_agent_status_check methods is deprecated but kept
for using in third part plugins for backward compatibility
2) new add_agent_status_check_worker, add_periodic_l3_agent_status_check
and add_periodic_dhcp_agent_status_check method are implemented
instead and are used for implementing plugins in neutron codebase
Closes-Bug: #1569404
Change-Id: I3a32a95489831f0d862930384309eefdc881d8f6
I think this needs a little more thought. This broke OVN at least and
I don't think that's good. We need to figure out how to be compatible
with existing plugins, even out of tree ones.
This reverts commit 1cafff0871.
Change-Id: Ie087fb11213cc85911483c2d32c463fa9c973e54
Forking a process when multiple threads are running is an unsafe
operation and could cause a lot of problems because only current
thread will continue working in child thread. Any locked by other
thread resource will remain locked forever.
We faced with this problem during oslo.messaging development and
added workaround to hide this problem:
https://review.openstack.org/#/c/274255/
I tried to fix this problem in oslo.service:
https://review.openstack.org/#/c/270832/
but oslo folks said that this fix is ugly and it is wrong way to add
workarounds to common libraries because projects use them incorrectly.
I think that is fair.
So this patch fixes incorrect usage of oslo libraries. In this patch
I extended functionality of NeutronWorker and add there
`worker_process_count` parameter which determines how many processes
should be spawned for this worker. If `worker_process_count` = 0 - don't
create process and spawn thread in scope of current process for worker
Then I moved all background tasks to workers and return them by
`get_workers` method. start_plugin_workers collects plugin's workers
using `get_workers` method and starts in ProcessLauncher first workers
with `worker_process_count` > 0 and only after this starts threaded
workers by simple Launcher
Closes-bug: #1569404
Change-Id: I0544f1d47ae53d572adda872847a56fa0b202d2e
In this patchset we stop the l3_router_plugin from loading the DNS integration
extension. The DNS integration extension should only be configured by the
operator by adding 'dns' to the 'extension_driver' list in ml2_conf.ini
Change-Id: I1321d9821973fe918005a8c2f3dd751af9affe38
Closes-Bug: #1574694
This patch adds HA support for DVR centralized default SNAT
functionality to Neutron Server. For the agent side changes
another patch has been merged.
Salient changes here are:
- Schedule/de-schedule SNAT on multiple agents
- Enables
'router-create <router name> --ha True --distributed True'
Closes-bug: #1365473
Co-Authored-By: Adolfo Duarte <adolfo.duarte@hpe.com>
Co-Authored-By: Hardik Italia <hardik.italia@hpe.com>
Co-Authored-By: John Schwarz <jschwarz@redhat.com>
Co-Authored-By: Oleg Bondarev <obondarev@mirantis.com>
Change-Id: I6a19481d0e19b8a55f32199a27057bf777548b33
An interface with an external DNS service is defined for Neutron. A reference
implementation is also included, based on Designate. The interface and the
driver will enable users to publish in the external DNS service the dns_name
and dns_domain attributes associated with floating ips, ports and networks. As
a consequence, the floating ips and networks api is extended to manage dns_name
and dns_domain attributes. The dns_name attribute was added to ports in a
preceding commit
DocImpact: Introduce config option external_dns_driver to specify a driver
for external dns integration. For more info, see
doc/source/devref/external_dns_integration.rst
APIImpact
Implements: blueprint external-dns-resolution
Change-Id: Ic298ad2558410ab9a614f22e1757d1fc8b22c482
This patch adds the availability_zone support for router.
APIImpact
DocImpact: Make router scheduler availability zone aware. If multiple
availability zones are used, set router_scheduler_driver =
neutron.scheduler.l3_agent_scheduler.AZLeastRoutersScheduler. This scheduler
selects agent depends on LeastRoutersScheduler logic within an availability
zone so that considers the weight of agent.
Change-Id: Id26d9494b9a5b459767e93a850f47a3b014b11bb
Co-Authored-By: IWAMOTO Toshihiro <iwamoto@valinux.co.jp>
Partially-implements: blueprint add-availability-zone
It's not used since the time we switched to oslo.messaging (Juno), it's
time to deprecate and eventually remove it.
Closes-Bug: #1506492
Change-Id: I57b0229c2b6028796cd10bbbfc9b166cf8a6dab0
This patch adds all RPC workers to consumers of service
plugins queues such as metering and l3-plugin.
This is important for DVR-enabled deployments with hundreds
of agents.
Change-Id: I6fea7f409c91b25d2c35b038d6100fdfa85d1905
Closes-Bug: #1498844
There are several cases where plugin initialization should be
handled after neutron-server forks API/RPC workers. For example,
starting a client connection to an SDN controller before forking
copies the fd of the socket to the child process, but then you have
multiple processes trying to read/write the same socket connection.
It is also useful for a plugin to be able to do something in only
one process, regardless of how many workers are forked. One example
would be handling syncing from an external system to the neutron
database.
This patch does 3 things:
1) Treats rpc_workers=0 as = 1. This simplifies the code for
handling notification that forking has completed. In the
existing code, calling the notification in the Worker object's
start() method would happen twice in the case where both api
and rpc workers were 0, despite there being only one process.
An earlier patch already changed the default api_workers to be
the number of processors.
2) Adds notification of forking via the callbacks mechanism.
Plugins can subscribe to resources.PROCESS, event.AFTER_CREATE
and do any post-fork initialization that needs to be done for
every spawned process.
3) Adds core/service plugin calls to get_workers() which defaults
to returning (). Plugins that need additional processes to spawn
should just return an iterable of NeutronWorkers that will be
spawned in their own process.
DocImpact
Closes-Bug: #1463129
Change-Id: Ib99954678c2b4f32f486b537979d446aafbea07b
Specify which resources should be tracked when initializing
the ML2 and l3_router plugins. This will enable usage tracking
for the following resources:
- Networks
- Ports
- Subnets
- Subnet pools
- Security groups
- Security group rules
- Routers
- Floating IPs
Partially implements blueprint: bp/better-quotas
Change-Id: I57287b15ffdadc30297651a01e9f05110e9ce6b6
log[1] decorator is deprecated, this change replaces it with oslo_log
log_method_call[2].
[1] neutron.common.log
[2] oslo_log.helpers.log_method_call
Change-Id: I61cf3c010e1f33a45ff700f4e8d4824ebdb378c7
Rodolfo Alonso Hernandez