Without this change pylint fails with:
neutron/objects/trunk.py:75:15: W0143: Comparing against a callable, did you omit the parenthesis? (comparison-with-callable)
Trivial-Fix
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I97f1dde896be114b81732ff74ab86a4a5be250e4
A non-vlan-transparent trunk parent port (tpt) should only forward
untagged frames. Earlier it was configured to forward anything (trunk
mode in ovs). This patch changes the trunk mode to access mode and
sets the trunk parent's tag explicitly to 0.
Change-Id: I4bcfe53fe87d7c9218dd0db9d7224bb323709a21
Closes-Bug: #2048785
The event registers check what type of event has happened and publish it
to the right subscriber based on it. Previously, the subscriber checked
again what type of event that is. That lead to the code double-checking
same variable. This patch removes the double-check and registers publish
the event to the correct subscriber right away.
Change-Id: Icdce95b5baffe02dbfa9320939efbfa46cb6757c
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
This reverts commit 955e621167.
Reason for revert: the port binding handling done in this patch is
incorrect and leads to issues during the cold migration process with
trunk ports in ML2/OVN.
Change-Id: Ifc2d37e2042fad43dd838821953defd99a5f8665
Closes-Bug: #2033887
This reverts commit 7ed79c1f78.
Reason for revert: the port binding handling done in this patch is
incorrect and leads to issues during the cold migration process with
trunk ports in ML2/OVN.
Change-Id: I642c3eb1771463db73248a8c50c0db6f7467a6d5
Partial-Bug: #2033887
During the trunk migration, the parent port multiple port binding
will contain the destination host. Because this update is done
before the migration is done (in other words, the parent port
still has two port binding registers), the method setting the
binding profile of the subport will use the destination host
in advance. At the end of the live migration, the subports
host will point to the correct hostname.
Related-Bug: #2027605
Change-Id: I2370ea2f96e2e31dbd43bf232a63394388e6945f
After updating pylint, it started emitting additional "W"
warnings in some cases, fix some of them.
modified-iterating-list,
implicit-str-concat,
global-variable-not-assigned
Trivialfix
Change-Id: I7deb5f1e0aa2852cb033c78dcb4c8bc87e34be1e
After updating pylint, it started emitting additional "R"
warnings in some cases, fix some of them.
use-a-generator,
unnecessary-lambda-assignment,
consider-using-max-builtin,
consider-using-generator,
consider-using-in,
use-list-literal,
consider-using-from-import
Trivialfix
Change-Id: Ife6565cefcc30b4e8a0df9121c9454cf744225df
This patch imitates the ML2/OVS Trunk driver behaviour. When the
trunk parent port is bound:
* A new trunk cannot be created using this parent port.
* If the port is assigned as parent port of a trunk, this
trunk cannot be deleted.
Closes-Bug: #2022059
Change-Id: I8cfa7e67524a42224cbb4b3c3cec3cfa49b795fd
The host ID and VIF details are added on the subport when the trunk is
created, if it's created when it's not attached to any VM this fields
will remain empty and be filled on the parent port when it gets bound
to a host, but there's no callback to add this info on the subport.
Closes-Bug: #2018289
Closes-Bug: #2024160
Change-Id: I34bb6f178c314907bdf9f76789777f6736938b67
When the subport binding information is updated in the OVN trunk
driver, the OVN revision number should be updated too, same as
in other ``ovn_client`` method, for example.
Closes-Bug: #2006734
Change-Id: Icda34910ea7fe308814e0cc60999b465d3540b67
The ``OVNTrunkHandler`` class updates the port binding profile of the
trunk subports. The methods ``_set_binding_profile`` and
``_unset_binding_profile`` update both the OVN LSP register and the
Neutron DB port register. This patch adds the missing field
"neutron:device_owner" from the LSP external_ids dictionary.
This patch also updates ``OvsdbNbOvnIdl.set_lswitch_port`` API method.
The method now accepts "external_ids_update" kwarg. This dictionary
allows to update (or add) individually each LSP.external_ids
dictionary key, instead of overwritting the whole variable.
NOTE: ``set_lswitch_port`` is not used outside Neutron now so this is
safe to change the API method signature.
Closes-Bug: #2006735
Change-Id: I985f3294b2ca7ab5989022ec1b904c8e29354e07
If "TRUNK_SKELETON" has not been initialized, the "unregister" method
should finish gracefully. This issue is happening in fullstalk tests,
where the trunk initialization is not executed if "trunk" is not in
the service plugins.
Closes-Bug: #2000314
Change-Id: Idef5fd8feaf1af309862d6cb3e06da3734fb6c19
Running with a stricter .pylintrc generates a lot of
C0330 warnings (hanging/continued indentation). Fix
the ones in neutron/services.
Trivialfix
Change-Id: Ie9779b257981bc80e69639cdaa4d7dfd0ffa5809
Prior to this change, trunk bridges are created by os-vif but deleted
by Neutron when the last vif is removed from it. This creates race
conditions in some use cases, like DPDK with vhostuserclient mode, when
VMs are rebooted. To avoid these races, Neutron will not delete trunk
bridges anymore. Their creation and deletion will be os-vif's
responsiblity. Since [1], Nova uses the os-vif version that contains
this functionality.
This patch also changes the trunk status change event. During a live
migration, when the trunk parent port has been bound to the destination
host (that means there is only one port binding associated) and the
status has changed to ACTIVE, the method triggers the subport binding
to the new host too. This is because there could be a race condition
between the subport binding, triggered by the OVS agent, and the parent
port binding, triggered by Nova. If when the OVS agent tries to bind the
subports, the parent port is still bound to the source host, the subport
binding remains in the source host too, instead of changing to the
destination.
This patch also reverts [2] and [3]. As commented in the previous
paragraph, this patch fixes the issue reported in LP#1997025. The trunk
port live migration with ML2/OVS must be fixed with this patch.
[1]https://review.opendev.org/c/openstack/nova/+/865031
[2]https://review.opendev.org/c/openstack/neutron/+/865295
[3]https://review.opendev.org/c/openstack/neutron/+/865424
Closes-Bug: #1869244
Closes-Bug: #1997025
Change-Id: I4e16357f3ff214fcf41e418982806c24088a2665
After a trunk VM has been migrated the trunk status remains
DOWN, After the parent port is back to active modify the trunk
status.
Closes-Bug: #1988549
Change-Id: Ia0f7a6e8510af2c3545993e0d0d4bb06a9b70b79
As a followup from the previous commit we here now also cleanup the
SubPort an Trunk fanout queues.
Closes-Bug: #1586731
Change-Id: I047603b647dec7787c2471d9edb70fa4ec599a2a
In Trunk service, the OVN was setting always the trunk to "ACTIVE"
anytime the trunk was created or updated. This patch changes this
behaviour: only when the trunk parent port belongs to OVN (that
means, there is a related logical switch port to this Neutron port),
the methods will set the trunk to "ACTIVE".
Closes-Bug: #1974183
Change-Id: Ied5ef53882d4249e0ceaa731239befdc3ba67d03
In [1] we added a delay before deleting DPDK vhu trunk bridges to
mitigate a race condition when instances are rebooted. As explained in
[1], with DPDK rhu, a reboot is esentially a super fast bridge
delete-then-create that is prone to race conditions. We have recently
encountered in customer deployments that the wait added in [1] is not
long enough. As a consequence, this change increases the wait.
[1] https://review.opendev.org/c/openstack/neutron/+/717394
Change-Id: I5c1474b405d436d3b1e5db745d77999f1723b660
Partial-Bug: #1869244
Subports of a trunk should have the same status as the parent port.
However, with ovn, if the parent port is in DOWN status, the subports
are transitioned to ACTIVE as soon as they are attached to the trunk.
This patch ensure the status set on the subports when being attached
matches the one on the parent port.
Closes-Bug: #1957161
Change-Id: I26c43c2909b635e8b21306ea1880da3877477a17
This reverts commit 101ccbaeb3.
Reason for revert: This commit is probably reason of some race condition
which causes random failures in the test_trunk_subport_lifecycle scenario
test.
Change-Id: Ia042384e0ac333f30235b76e50fdc8748fc2b29a
Closes-Bug: #1943708
When trunk or subport is created or deleted, notifications are sent. In
the meanwhile, subport status is not updated accordingly.
device_id device_owner and binding:host_id should be updated when
notifications are received.
In this patch, notifications are listened and subport status should be
updated when trunk/subport is created and subport is already added to
trunk:
device_id: <trunk_id>
device_owner: trunk:subport
binding:host_id: <parent port host_id>
When trunk/subport is deleted or subport is removed from trunk, subport
status should be updated:
device_id: None
device_owner: None
binding:host_id: None
Closes-Bug: #1942413
Change-Id: I0bdc5aabae0125926253b530fd0c6e79ba7bcbb9
It is possible for events from the nb/sb to fire before the opposite
db connection is made. These events can call back into driver code
which tries to access the other db before it is connected.
Closes-Bug: #1929197
Closes-Bug: #1928794
Closes-Bug: #1929633
Change-Id: If947581b90ced42981c4611c32de8f428a052c69
The SubPortNotFound exception gets the port id of the subport that was
not found. This is now correctly labeled as SubPort, not as parent port
anymore.
Change-Id: I6e33ff4a7e0cb7864535a0905b5dc197a0aa8a5d
This reverts commit 062336e59b.
Now, we have proper fix for the system_scope='all' in elevated context
in the neutron-lib so we can revert temporary fix made at the end of the
Wallaby cycle.
Related-Bug: #1920001
Conflicts:
neutron/api/rpc/agentnotifiers/dhcp_rpc_agent_api.py
neutron/common/utils.py
neutron/db/address_group_db.py
neutron/services/segments/db.py
Change-Id: Ife9b647b403bdd76a8a99984ea8858bf95c96bc3
Load the Linux Driver Trunk agent extension driver only if the service
plugin is enabled. If the service plugin is not enabled, the agent
extension will not subscribe to the port events.
Change-Id: I883abb5ef122ac7f8fb029d0334fa2d68893f8aa
Closes-Bug: #1930443
This patch switches the code over to the payload style of callbacks [1]
for TRUNK and SUBPORTS events. As needed existing callbacks are shimmed
to support both payload and kwarg style callbacks. These shims will be
removed once all callbacks are switched over to payloads.
Also the neutron.services.trunk.callback module is removed as consumers
will no longer need the TrunkPayload therein.
NeutronLibImpact
[1]
https://docs.openstack.org/neutron-lib/latest/contributor/callbacks.html
Change-Id: Ie302b48b283f8780072b5c9e2bc8787d87c11794
In case when enforce_new_defaults is set to True and new policy rules
are used, context.is_admin flag isn't really working as it was with old
rules.
But in case when elevated context is needed, it means that we need
context which has full rights to the system. So we should also set
"system_scope" parameter to "all" to be sure that system scope queries
can be done with such elevated context always.
It is needed e.g. when elevated context is used to get some data from
db. In such case we need to have db query which will not be scoped to
the single project_id and with new defaults to achieve that system_scope
has to be set to "all".
Proper fix for that should be done in neutron-lib and it is proposed
in [1] already but as we are have frozen neutron-lib version for
stable/wallaby already this patch for neutron is temporary fix for that
issue.
We can revert that patch as soon as we will be in Xena development cycle
and [1] will be merged and released.
[1] https://review.opendev.org/c/openstack/neutron-lib/+/781625
Related-Bug: #1920001
Change-Id: I0068c1de09f5c6fae5bb5cd0d6f26f451e701939
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
Use case: many trunk ports (300+) each with many subports.
Issue: get_ports takes much time.
Solution: apply trunk resource extend func for a full list of ports,
not for each port individually, thus avoiding a DB query for each
trunk port.
The approach will be extended for other resource extenders, like QoS,
and probably for other resources as well.
QoS: https://review.opendev.org/c/openstack/neutron/+/764454
Change-Id: Ic08e4049f6156c0700ca3c7aee251b6eb0eb97da
Closes-Bug: #1905268
"@abc.abstractproperty" is deprecated since 3.3. Now it's possible
to use "@property" on top of "@abstractmethod".
Change-Id: I0cca37b626a94a05fb983a8528c22a660e89e673
As spotted in Focal testing patch [0], pep8 test fails with many
C0321 false-positives, reported in pylint as current version does not
support python 3.8 [1]
Use a newer version of pylint and astroid, fixing or disabling some of
the new checks: no-else-*, unnecessary-comprehension, import-outside-toplevel
[0] https://review.opendev.org/#/c/738163/
[1] https://github.com/PyCQA/pylint/issues/2737
Change-Id: Ie646b7093aa8634fd950c136a0eba9adcf56591c
DPDK vhostuser mode (DPDK/vhu) means that when an instance is powered
off the port is deleted, and when an instance is powered on a port is
created. This means a reboot is functionally a super fast
delete-then-create. Neutron trunking mode in combination with DPDK/vhu
implements a trunk bridge for each tenant, and the ports for the
instances are created as subports of that bridge. The standard way a
trunk bridge works is that when all the subports are deleted, a thread
is spawned to delete the trunk bridge, because that is an expensive and
time-consuming operation. That means that if the port in question is
the only port on the trunk on that compute node, this happens:
1. The port is deleted
2. A thread is spawned to delete the trunk
3. The port is recreated
If the trunk is deleted after #3 happens then the instance has no
networking and is inaccessible; this is the scenario that was dealt with
in a previous change [1]. But there continue to be issues with errors
"RowNotFound: Cannot find Bridge with name=tbr-XXXXXXXX-X". What is
happening in this case is that the trunk is being deleted in the middle
of the execution of #3, so that it stops existing in the middle of the
port creation logic but before the port is actually recreated.
Since this is a timing issue between two different threads it's
difficult to stamp out entirely, but I think the best way to do it is to
add a slight delay in the trunk deletion thread, just a second or two.
That will give the port time to come back online and avoid the trunk
deletion entirely.
[1] https://review.opendev.org/623275
Related-Bug: #1869244
Change-Id: I36a98fe5da85da1f3a0315dd1a470f062de6f38b
When trunk port deletion is attempted but fails because the driver does
not permit it, the logs do not contain the driver error message that
specifies the precise rationale for preventing the trunk port deletion.
Log it explicitly.
Change-Id: I7ed1a742849dfce9e65b8eb36566112501fb0e39