All of the externally consumed variables from neutron.common.constants
now live in neutron-lib. This patch removes neutron.common.constants
and switches all uses over to lib.
NeutronLibImpact
Depends-On: https://review.openstack.org/#/c/647836/
Change-Id: I3c2f28ecd18996a1cee1ae3af399166defe9da87
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>
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 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
Inter Tenant Traffic between two different networks that belong
to two different Tenants is not possible when connected through
a shared network that are internally connected through DVR
routers.
This issue can be seen in multinode environment where there
is network isolation.
The issue is, we have two different IP for the ports that are
connecting the two routers and DVR does not expose the router
interfaces outside a compute and is blocked by ovs tunnel bridge
rules.
This patch fixes the issue by not applying the DVR specific
rules in the tunnel-bridge to the shared network ports that
are connecting the routers.
Closes-Bug: #1751396
Change-Id: I0717f29209f1354605d2f4128949ddbaefd99629
Changing rpc_api.rst file path from doc/source/devref/rpc_api.rst
to /doc/source/contributor/internals/rpc_api.rst. Because rpc_api.rst
file is located at this path
doc/source/contributor/internals/rpc_api.rst.
Closes-Bug #1722072
Change-Id: Ic243aab9e3428bfec69db61a94b4129cd768e233
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 updates docstring for get_ports_on_host_by_subnet, to
tell that the method will only get dvr serviced ports, not all ports
for given subnet and host.
Change-Id: I85ea5a9e37b6c894f7d51e73c10143b208a29f0e
In DVR routers when a port is added to a router, then
the command succeeds but the l2 ovs agent raises an
error stating that it could not retrieve the gateway
port for the subnet.
The reason for this is there is mismatch in the
ip_address returned from the subnet for the gateway
port and the actual ip_address of the port that we
added to the router.
Since the subnet info was passed to "get_subnet_for_dvr"
this mismatch was seen.
Instead of passing the subnet we will be passing the
actual fixed_ips with all the details and the subnet
gateway port will be filtered based on the ip_address
in the fixed_ips passed.
Closes-Bug: #1404823
Change-Id: I87a3983951f814350e79f5e2274f4639bb6bc0f5
oslo.log now provides a logging helper that is similar to custom neutron
helper (actually, the helper in oslo.log started from neutron version).
Now switching to library implementation.
Deprecated neutron.common.log.log
Change-Id: I85d5fc570950ff18cfdb8db20ad20b166e195299
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
This patch does a couple of things. First it adds docstrings to the
client/server pair of the rpc interface used by the ovs agent
to make dvr related calls back into the Neutron server. The docs
tell you where the other side of the interface is found in the code,
and where docs are that give more info on the rules for changing them.
The second thing done in this patch is to scope this interface using a
messaging namespace. Right now some plugins expose several interfaces
via the default namespace. This effectively means they are a single
API and should be managed with a single version stream. It's much
more managable to just treat these as separate interfaces and this
change makes that explicit and functionally true. Now when a method
is invoked, the only classes considered for handling that request will
be ones marked with the right namespace.
Part of blueprint rpc-docs-and-namespaces.
Change-Id: Ieb1f023f5ab0ba66620d07e90005a49f1d40574c
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
Replace DVRServerRpcApiMixin with a standalone rpc client class,
DVRServerRpcApi. Also convert the one user of this code (the ovs
agent) to use it. This is a prerequisite to being able to put this
rpc interface into a messaging namespace.
Part of blueprint rpc-docs-and-namespaces.
Change-Id: I33b8bff78fd9ca0223c5e48713f7e8f2db026752
Remove usage of the RpcProxy compatibility class from the ml2
AgentNotifierApi. The equivalent oslo.messaging APIs are now used
instead. A couple of other mixin APIs had to be converted at the same
time.
Note that there is one very minor functional change here. The base
rpc version is set to '1.0' now instead of '1.1'. The right pattern
to use is to always set the base to be N.0. Any method that needs a
newer version should specify it.
Part of blueprint drop-rpc-compat.
Change-Id: I640568e2d73c9eb7a9505db640dc1427a1ae2abe
Fix the usage of call methods as per recent changes according to
drop-rpc-compat. These changes went overlooked and it broke DVR.
Tests will be done as follow-up.
Partial-bug: #1394848
Change-Id: I6e0584f8e54e606a76b87853b2371cc8e24eba69
This patch drops several uses of the RpcCallback compatibility class.
All of these were trivial and straight forward conversions so I
batched them up.
There are still several other uses of RpcCallback, but the conversions
are were not necessarily trivial, and may be broken in one way or
another, so I wanted to address them separately. In particular, the
use of mixin classes means that there could be cases where the version
declaration is being stepped on, so they need to be investigated more
closely.
Part of blueprint drop-rpc-compat.
Change-Id: I0977aee863d4fcc6a14a025215c6e41fe38a87f0
The initialization, as well as the recurrent checks on whether the agent
is able to handle DVR requests, are not necessary; this is because the
dvr_agent is going to be set at the time the L2 agent starts receiving
RPC messages.
Change-Id: I9caad965d0ff507e2ed93d6432997ad86139ac04
RPC has a version of itself. In Neutron a plugin implements
several RPC interface, so a single RPC version doesn't work.
In Mixin callback class approach, RPC versioning depends on
each plugin implementation and it makes harder to maintain
RPC version appropriately. This patch series replaces mixin
RPC callback of server side with a separate class.
This commit handles server-side callback of DVR ML2 RPC interface.
Partial-Bug: #1359416
Change-Id: I1b6383f7b0af5d9aed18eda3a15f21d3504d0347
Currently, DVR router namespaces are created only
when there is a valid VM port on the compute
node, or for the gateway-port on the service node.
But when an LBaaS VIP port is created the l3 agent
does not create a DVR namespace to service the VIP port.
This fix enables DVR namespaces to be created to
service the LBaaS VIP port.
Also, this fix enables L2 Agent running in DVR
mode, to add-in OVS rules to enable packets to
be routed to such LBaaS VIP Ports which are
resident on DVR routed interfaces.
Therefore, with this fix both East-West and
North-South traffic will be serviced by DVR
for LBaas VIP Ports.
DocImpact
Authored-by: Swaminathan Vasudevan <swaminathan.vasudevan@hp.com>
Co-Authored-By: Vivekanandan Narasimhan <vivekanandan.narasimhan@hp.com>
Change-Id: I698b971d50721fb0512a11569f7d3139d0d456f3
Closes-Bug: #1356464
RpcProxy sets by default topic=self.topic, there's no need to specify
it explicitly in derived class, unless it is overridden
Change-Id: I19b9a67072a7f3c42e3b0e4ba412241a056a79a3
Closes-bug: 1348180
This patch introduces the RPC contract changes
required for both the server (plugin) and agent
to propagate and retrieve additional information
about Distributed Routers, like MAC addresses
and Port Bindings.
Partially-implements: blueprint neutron-ovs-dvr
Change-Id: I04a2ee5fceea79d2786c799178f8dd1675925a39
Authored-by: Vivekanandan Narasimhan <vivekanandan.narasimhan@hp.com>
Co-Authored-By: Armando Migliaccio <armamig@gmail.com>
Boden R