When a DVR router is migrated from distributed to
centralized, we are unbinding the router from the
agents, but the ml2 distributed portbindings for
the router port still remains intact.
This patch will fix the issue by deleting the
binding entry for multiple hosts.
Closes-Bug: #1718345
Change-Id: If139790eb336ff13b07b094151946af30322ad3e
(cherry picked from commit 32bfc3edec)
In method _generate_arp_table_and_notify_agent in neutron.db.l3_dvr_db
module notifiations about arp table was send only to one router
connected to subnet.
Now it will check if subnet is connected to more than one
dvr router and will send same notification to all such routers.
Closes-Bug: #1815913
Change-Id: I6a7d7f6645a8a7b5219788d51e17d54844d145bc
(cherry picked from commit 1f104a093c)
When associating a floating IP to a port and the router is distributed,
the VNIC type of this port must be "normal" only. In any other case,
the floating IP can't be assigned. For example, a SR-IOV can have a
floating IP if the router is distributed (the router is in the same
host of the port).
This patch adds also function can_port_be_bound_to_virtual_bridge to
neutron/db/l3_db.py module.
Originally this function was introduced in neutron-lib with [1] but
in stable branch there is older neutron-lib used so this isn't available
from neutron-lib.
[1] https://review.openstack.org/#/c/615126/
Closes-Bug: #1566951
Change-Id: I4944041df81e24683bc612560808bcdcc2db6bf2
(cherry picked from commit 1966ad3945)
During L3 agent restart, the dvr ha router gateway port
binding host may change because the multiple ha router
scheduled hosts.
After this patch, we return the 'master' ha binding host
directly during the gateway port create. And do not let
the original 'master' (current is backup) host override
the gateway port binding host.
Closes-Bug: #1793529
Change-Id: Icb2112c7f0bd42c4f4b1cf32d6b83b6d97f85ef7
(cherry picked from commit 1973a037c2)
If router gateway info update, in l3_dvr_db will receive events,
We will get subnets from router attached DVR port, if exists
multiple IPv6 slaac-enabled subnets, previous code will create
csnat port form one of the IPv6 subnets.
This is inconsistency with router interface
udpate in _update_snat_v6_addrs_after_intf_update.
This patch adds all IPv6 subnets if the distributed
router port have multiple IPv6 subnets.
Change-Id: I02ffed238897ebc91b96aebb7f94ed90b7613769
Closes-Bug: #1786169
(cherry picked from commit c6aac9041f)
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
This is an additional test for deleting csnat port when
migrating DVR router to HA router.
Change-Id: I4a2365fe3a64b65034280558ffe6312d8dabd600
Partial-Bug: #1714251
With a recent change to the neutron server code, the server was
processing floating IPs that were not bound to the respective
agent during fullsync operation.
Change to always initialize floating IP host info so callers
can determine if info should be sent to an agent or not.
Also changed the logic that decides when the server should
send a floating IP to an agent to be easier to understand.
Closes-bug: #1713927
Change-Id: Ic916225e0a11c3fb8cd94437ca063e0d3295a569
When trying to add routerport as router OVO's synthetic field,
the routerport should be eagerly loaded in router db.
Router OVO creation PS: I6df6b9d90c6a7281edc39cfafd9ea33e9a7a0b34
Change-Id: I5dcf9dc358c1122b2b22a6c4f40ae0b170e2003c
When a router is migrated from DVR to HA or DVR to centralized router,
router_centralized_snat port still exists in DB. When the router is no
more a DVR router, this port is useless and has to be removed from DB.
This patch removes router_centralized_snat port when a router is
migrated from DVR to other modes.
Closes-Bug: 1714251
Change-Id: I124514d021ff8539ac3a628907cb49611ef66d08
When router interfaces are added to DVR router, if the router has
gateway configured, then the internal csnat ports are created for
the corresponding router interfaces.
We have seen recently after the csnat port is created if the
RouterPort table update fails, there is a DB retry that is happening
and that retry operation is creating an additional csnat port.
This additional port is not getting removed automatically when the
router interfaces are deleted.
This issue is seen when testing with a simple heat template as
per the bug report.
This patch fixes the issue by calling the RouterPort create with
delete_port_on_error context.
Change-Id: I916011f2200f02556ebb30bce30e349a8023602c
Closes-Bug: #1709774
Unbound ports that are associated with a Floating IP and connected to
DVR Routers will not be serviced by the DVR Routers, unless we bind it
to a valid host.
This server side patch allows the neutron server to schedule the
unbound port Floating IP on the network node or the node with dvr_snat
agent where the SNAT functionality resides.
The DNAT rules for the unbound ports will be configured in the SNAT
namespace on the network node.
Related-Bug: #1583694
Change-Id: I05d0bfb3fa275b1e4e479928000cf8494da858f6
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
The callback modules have been available in neutron-lib since commit [1]
and are ready for consumption.
As the callback registry is implemented with a singleton manager
instance, sync complications can arise ensuring all consumers switch to
lib's implementation at the same time. Therefore this consumption has
been broken down:
1) Shim neutron's callbacks using lib's callback system and remove
existing neutron internals related to callbacks (devref, UTs, etc.).
2) Switch all neutron's callback imports over to neutron-lib's.
3) Have all sub-projects using callbacks move their imports over to use
neutron-lib's callbacks implementation.
4) Remove the callback shims in neutron-lib once sub-projects are moved
over to lib's callbacks.
5) Follow-on patches moving our existing uses of callbacks to the new
event payload model provided by neutron-lib.callback.events
This patch implements #2 from above, moving all neutron's callback
imports to use neutron-lib's callbacks.
There are also a few places in the UT code that still patch callbacks,
we can address those in step #4 which may need [2].
NeutronLibImpact
[1] fea8bb64ba7ff52632c2bd3e3298eaedf623ee4f
[2] I9966c90e3f90552b41ed84a68b19f3e540426432
Change-Id: I8dae56f0f5c009bdf3e8ebfa1b360756216ab886
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
This eliminates the mixin references in DVRResourceOperationHandler
to prepare for it to be used by the DVR service provider and to be
removed from the main L3 plugin mixin.
Related: blueprint multi-l3-backends
Change-Id: I5ab6b92b67e6d3b461fd118ef0a26d6f6b6992c4
In order to route traffic between the internal subnets and the
external subnet that belong to the same address_scopes we need
to create the gateway port and the fip namespace irrespective of
the configured floatingips for the internal subnet.
This will consume an additional IP from the external subnet on
all nodes, but with the introduction of service_type networks,
this will not be an issue any more.
This patch is the first in series that creates the agent gateway
port and the fip namespace on every node when the gateway is set
for the router. For every router created it will connect the
router namespace to the fip namespace.
Partial-Bug: #1577488
DocImpact: Document the change in behavior for fip-agent-gw create
Change-Id: I30c4f7fc250e486fe9a71b68540e783e90a6cf15
Neutron-lib 1.1.0 is now out and contains the portbindings
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
portbindings API extension must now use the values
from neutron-lib.
[1] 87e42f993c07ae320159d5123662ee9f3bd4d903
Change-Id: I669af9b4c712877772d91a03857ab108714001d4
Usage reader and writer for db operations.
In Neutron code we have common situation like:
with context.session.begin():
context.session.add(obj)
self._make_obj_dict(obj)
With new enginefacade we change context.session.begin() for
db.context_manager.writer(reader).using(context).
When object leaves this with-block, its reference to session is
cleared because session is discarded. To use this object later to
load some data from its dependencies, we have to provide different
session to work in. To solve this obj either can be moved under
with-block or we have to do context.session.add(obj) one more time
to be able to load relations.
This change also switches to usage of new enginefacade for some db
operations with ports, in order to pass unit and functional tests.
Partially-Implements blueprint: enginefacade-switch
Change-Id: Ia15c63f94d2c67791da3b65546e59f6929c8c685
This patch proposes the allowance of changing a router's 'distributed'
or 'ha' attributes without any restriction as to the previous state of
these attributes, as long as the router's admin_state_up is False.
Closes-Bug: #1654991
Change-Id: Iad4dd77f74ba01876e0091112a1e24a3463993d1
When updating router gateway to another external network, original csnat
ports are deleted in db, but no new ports are created because the
_create_snat_interfaces_after_change method did't take the network
change into account.
To reduce the complexity of operation taken by l3 agent caused by the
csnat ports change, we don't need to delete original csnat ports.
This patch will skip the csnat port deletion if it is a network change.
Change-Id: Id8e89daa339424bb3c5efdffd0a59cfed005bb5d
Closes-Bug: #1651813
DVR had a complete copy and paste of the l3_db
add_router_interface. This patch gets rid of that
by adding in a some args to existing callbacks. \o/
This also has a variable rename from 'new_port' to
'new_router_intf' to clearly indicate that it's referring
to the creation of a new router interface regardless of
the creation of a core plugin port.
Change-Id: I6192c41419a992be9d0ded338f7a87ebcefda6af
This function was added as part of [1] as a way to
prevent _find_ipv6_router_port_by_network from returning
the DVR SNAT port. However, the same thing can be
achieved by making _find_ipv6_router_port_by_network
just check that the interface matches the expected
device owner for regular router interfaces before
returning it.
This function is the last inherited function in the
DVR mixin other than _get_device_owner.
Once a solution for _get_device_owner and the
router extra attributes processing is found, all of
this code can be moved out of the mixin in to the
DVR driver.
1. Id243a4b3f30071226411ace6d12550fc099901cc
Change-Id: I9923ac41914dcf2e6f047517215e4c1c2d754db3
When migrating a HA router to legacy, the router's interface (whose
device_owner is network:ha_router_replicated_interface) isn't changed
to network:router_interface. This means that certain actions (such as
trying to use 'neutron router-interface-delete' and migrating the router
to DVR) won't work (since a router interface of the appropriate type
can't be found and an SNAT port won't be created, respectively). This
patch takes care of the needed migration.
Closes-Bug: #1645716
Change-Id: I0c18ccf08ddfa57fde9b5ac331101497079bd330
Switch to a callback based approach for cleaning up the
distributed resources for a router gateway. This maintains
the current transactional semantics and gets us closer
to eliminating the use of mixins for DVR.
Change-Id: I1d17706652811383d4bc968812d5cd6526febc4b
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 stops the DVR mixin from overriding the '_update_fip_assoc'
function in order to create its agent floating IP gateway ports.
It instead now subscribes to the floating IP AFTER_UPDATE event
to create these ports.
Additionally, it fixes the semantics of the floating IP AFTER_UPDATE
event so it's emitted after the update is committed to the DB
so it's safe to call core plugin mutation methods and external systems.
In addition to fixing the callback semantics, this is part of the
effort to eliminate GUARD_TRANSACTION in-tree, which
should pave the way for ML2 to adopt the new engine facade and for
push notifications to safely transmit the latest DB state.
Related-Bug: #1540844
Partially-Implements: blueprint push-notifications
Partially-Implements: blueprint enginefacade-switch
Change-Id: I93e4d847f96707b17c4a7dfdb3bbf81d062fe3fb
Attaching a subnet to a router may be forbidden in some cases.
To prevent this attachment, we need to send a BEFORE_CREATE event
with "router_interface" as resource, and reraise any exception
that tells neutron a third party code forbid this attachment.
Change-Id: Ia71e0c5e9e3e073053ead7e1e7c3040087f5ee13
Closes-bug: 1537091
From this patch: https://review.openstack.org/#/c/341427/
Sometimes, port doesn't revert device_owner to previous value
in concurrent requests case.
This patch fixes this problem and adds unit test.
Change-Id: I864a559f0316e164caa065abd75c44fae971b571
Closes-Bug: #1621750
If a CSNAT port update fails when a subnet is added,
it will leave the regular updated router port in the
changed state since it's a separate port update with
a separate transaction. So when the CSNAT update fails
we need explicitly undo the 1st update with another update.
Closes-Bug: #1609693
Change-Id: If979aebbebf6da77f3fcec0cc7ec8b27e388aba4
The code assumed every port returned from the csnat port query
would have a fixed_ip that it could compare the subnet it is
looking for to. This should be a valid assumption however there
is a path leading to a condition where it has no IPs. This makes
the cleanup code handle this case and dump a warning until we can
figure out what causes the interface to lose the IP.
Partial-Bug: #1609540
Change-Id: Ida024a231bb3fc09dad0e80498f57a5761ca3420
Stevedore documentation suggest that full import paths are not supposed
to be user visible. Since unit tests emulate users when configuring
oslo.config, we better off relying on well known plugin aliases than
internal details.
For in-tree that may be not a big deal, but with it we set a bad example
for third parties that may later find their tests broken eg. when we
decide to move code around.
TrivialFix
Change-Id: I7bd036ac3df7e7f4c678356d0a793e7d38599dda
Current code will prevent from deleting router centralized snat port,
when there is a ipv6 subnet attatched to DVR.
This is correct when deleting a v6 router centralized snat port, because
multiple v6 subnets share one router port.
But it is not correct when deleteing a v4 router centralized snat port,
because v4 subnet doesn't share router port with v6 subnet. Deleteing a
v4 router centralized snat port should be allowed no matter if there is
v6 subnet attached to DVR.
Change-Id: I2d06c8c79f9ff9a9300a94bcbbae13569e4d963e
Closes-bug: #1581348
Today DVR routers are created after a dvr service port is
seen on a given node. But in the case of instance live
migration, the creation of l3 routed networks on the
destination node is delayed since we react to the event.
This patch tries to proactively create routers on the
destination node based on the portbinding profile info
updated by the nova when the instance is on a pre-migration
state.
Nova calls setup_network_on_host during the pre-migration
phase and we update the portbinding profile dict with
an attribute 'migrating_to' as shown below
port:{'binding:profile':{'migrating_to': 'host'}}
where 'host' points to the 'destination' of the port.
L3 plugin will verify the migration profile for the port on
any port update and then take action to create routers in the
respective agents if routers have not been created.
If the live migration fails or if reverted, then the port
binding profile attribute 'migrating_to' will be cleared from
the port profile. In this case, the router and the fip namespace
may be created on the destination node, but since the VM did
not land on the destination node, it would not cause any issues,
since the traffic will still be flowing out from the origination
node, except for the existence of the router and fip namespace.
For some reason if the creation of the router namespace and fip
namespace fails, then the live migration may still proceed as
it is now and the agent will create the router namespace and fip
namespace reactively.
The case were we report status back to Nova and Nova reacting
to the setup_networks_on_host status will be handled in the
upcoming release.
This patch should not affect any upgrades with respect to the
agent or server.
Change-Id: Ibb62f012333cfdfd468bafdc0b4501aa46b4b54d
Related-Bug: #1456073
Swaminathan Vasudevan