During the live migration trunk subports where updated only based
on the "host_id" field. But when rpc message to update subports
is send trunk's port is still bound to the old host and has
"migrating_to" field in binding:profile set to the new host.
Because of that binding:host_id for the subport's port wasn't updated
proberly and port was set to DOWN on the new host.
That could even cause connectivity break if L2population is used in the
cloud.
This patch fixes that by updating subport's binding:host_id field based
on the migrating_to field if that is available and not empty.
Closes-Bug: #1914747
Change-Id: I98e55242d381ada642ca0729e9aefdea7628c945
assertItemsEqual was removed from Python's unittest.TestCase in
Python 3.3 [1][2]. We have been able to use them since then, because
testtools required unittest2, which still included it. With testtools
removing Python 2.7 support [3][4], we will lose support for
assertItemsEqual, so we should switch to use assertCountEqual.
NOTE(dmllr): added hacking check
[1] - https://bugs.python.org/issue17866
[2] - https://hg.python.org/cpython/rev/d9921cb6e3cd
[3] - testing-cabal/testtools#286
[4] - testing-cabal/testtools#277
Change-Id: I7c20fec08e5dc9f67b34100c925ea6724bbd25f0
Now that we are python3 only, we should move to using the built
in version of mock that supports all of our testing needs and
remove the dependency on the "mock" package.
This patch moves all references to "import mock" to
"from unittest import mock". It also cleans up some new line
inconsistency.
Fixed an inconsistency in the OVSBridge.deferred() definition
as it needs to also have an *args argument.
Fixed an issue where an l3-agent test was mocking
functools.partial, causing a python3.8 failure.
Unit tests only, removing from tests/base.py affects
functional tests which need additional work.
Change-Id: I40e8a8410840c3774c72ae1a8054574445d66ece
In patch [1] as partial fix for bug 1828375 retries mechanism
was proposed.
We noticed that sometimes in have loaded environments 3 retries
defined in [1] can be not enough.
So this patch switches to use neutron_lib.db.api.MAX_RETRIES constant
as number of retries when processing trunk subport bindings.
This MAX_RETRIES constant is set to 20 and in our cases it "fixed"
problem.
[1] https://review.opendev.org/#/c/662236/
Change-Id: I016ef3d7ccbb89b68d4a3d509162b3046a9c2f98
Related-Bug: #1828375
This is an approximate partial fix to #1828375.
update_trunk_status and update_subport_bindings rpc messages are
processed concurrently and possibly out of order on the server side.
Therefore they may race with each other.
The status update race combined with
1) the versioning feature of sqlalchemy used in the standardattributes
table and
2) the less than serializable isolation level of some DB backends (like
MySQL InnoDB)
does raise StaleDataErrors and by that leaves some trunk subports in
DOWN status.
This change retries the trunk status update (to BUILD) blindly when
StaleDataError was caught. In my local testbed this practically
fixes #1828375.
However theoretically the retry may cover up other real errors (when the
cause of the StaleDataError was a different status not just a different
revision count).
To the best of my understanding a proper fix would entail guaranteeing
the in order processing of the above rpc messages - which likely won't
ever happen.
I'm not sure at all if this change is worth merging - let me know what
you think.
Change-Id: Ie581809f24f9547b55a87423dac7db933862d66a
Partial-Bug: #1828375
The trunk constants now live in neutron-lib. This patch consumes them
by removing neutron.services.trunk.constants and using them from
neutron-lib instead.
Depends-On: https://review.opendev.org/#/c/650372/
NeutronLibImpact
Change-Id: I4445c44c7e321d0fc35976d4d855c148bb9a3b18
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 common rpc and exceptions were rehomed into
neutron-lib with [1]. This patch shims those rehomed
modules in neutron to switch over to neutron-lib's
versions under the covers.
To do so:
- The rpc and common exceptions are changed to
reference their counterpart in neutron-lib effectively
swapping the impl over to neutron-lib.
- The fake_notifier is removed from neutron and lib's
version is used instead.
- The rpc tests are removed; they live in lib now.
- A few unit test related changes are required
including changing mock.patch to mock.patch.object,
changing the mock checks for a few UTs as they don't
quite work the same with the shim in place.
- Using the RPC fixture from neutron-lib rather than
that setup in neutron's base test class.
With this shim in place, consumers are effectively using
neutron-lib's RPC plumbing and thus we can move consumers
over to neutron-lib's version at will. Once all
consumers are moved over we can come back and remove
the RPC logic from neutron and follow-up with a consumption
patch.
NeutronLibImpact
[1] https://review.openstack.org/#/c/319328/
Change-Id: I87685be8764a152ac24366f13e190de9d4f6f8d8
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
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 implements state management for trunks, allowing the trunk
state machine to be driven by the various events in the
lifecycle of a trunk. All events are handled here with the exception
of the unbinding of the parent port of a trunk.
Change-Id: I08341317f2cf6f4d1fc798773448ca0a79b242f5
Partially-implements: blueprint vlan-aware-vms
This patch introduces the RPC backbone required for the trunk plugin to work
with agent-based L2 drivers (like Open vSwitch); to this aim it uses the RPC
callback registry to send/receive trunk and subports OVOs over the wire.
More patches will follow up to complete the RPC integration; some stuff is
still work in progress, but there is enough substance that make this
patch worth it.
Partially-implements: blueprint vlan-aware-vms
Co-Authored-By: Ryan Tidwell <ryan.tidwell@hpe.com>
Co-Authored-By: Armando Migliaccio <armamig@gmail.com>
Co-Authored-By: Adolfo Duarte <adolfo.duarte@hpe.com>
Change-Id: I3c749e9287cc778e12d3e022ddfd157ac9c1569b
Rodolfo Alonso Hernandez