Commit 90212b12 changed the OVS agent so adding vital drop flows on
br-int (table 0 priority 2) for packets from physical bridges was
deferred until DVR initialization later on. But if br-int has no flows
from a previous run (eg after host reboot), then these packets will hit
the NORMAL flow in table 60. And if there is more than one physical
bridge, then the physical interfaces from the different bridges are now
essentially connected at layer 2 and a network loop is possible in the
time before the flows are added by DVR. Also the DVR code won't add them
until after RPC calls to the server, so a loop is more likely if the
server is not available.
This patch restores adding these flows to when the physical bridges are
first configured. Also updated a comment that was no longer correct and
updated the unit test.
Change-Id: I42c33fefaae6a7bee134779c840f35632823472e
Closes-Bug: #1887148
Related-Bug: #1869808
(cherry picked from commit c1a77ef8b7)
There were duplicated methods doing almost the same in terms
of OVS/OVN compilation.
This change:
* move of OVS related compilation code to devstack/lib/ovs
* delete of OVS related compilation code from devstack/lib/ovn_agent
* source unified functions in devstack/lib/ovn_agent from
devstack/lib/ovs
* Unify NEUTRON_PATH variable to NEUTRON_DIR
Stable-specific change:
* Sets default variable for OVN_BRANCH to point latest
stable release
Conflicts:
devstack/lib/ovn_agent
Closes-Bug: #1877377
Change-Id: Ia012a8e116a276a6674f86366c803e0e2d8ff704
(cherry picked from commit fb2806f808)
Instead of adapting to changes to the tripleo inventory structure let
ansible parse it for us using ansible-inventory.
Change-Id: I34ad0fd5feed65dd1266993a77f6ebc69fecfdfb
Closes-bug: #1884764
(cherry picked from commit aa6491a9d9)
In patch [1] we moved neutron_tempest_plugin test executions to
neutron-tempest-plugin repository.
That moves us forward with unifying the way of executing tests
after OVN merge.
[1] https://review.opendev.org/#/c/734832/
Change-Id: Iecca2649fc5e066fabe7f4b4746094506b595f0b
(cherry picked from commit 193df8279d)
We have separate project now - OVN Octavia provider - and its gate
is responsible for testing OVN integration with Octavia.
Change-Id: I317b7ad54a2f5c5c99bf0bff9eba4d91a1a86491
(cherry picked from commit b64d934964)
There is a bug in OVN functional tests, where it looks for datapath binding
of just created network.
In rare conditions datapath binding entry could not be in place in time,
because it is a ovn-northd responsibility to create it and we don't lock
this process in neutron api.
Change-Id: Ice115623491ad5b50397a0338f0a7780dc05d24c
Closes-Bug: #1884986
(cherry picked from commit 598e0376c6)
This resolves a bug that causes stale records to be kept in place when
an admin deletes a port, server or floating IP that was created in some
project other than the admin project.
Change-Id: I7cbb0e87a7e87f23ccf5d8750835b4785693473a
Closes-Bug: #1875981
(cherry picked from commit 622714b63e)
Subnet delete triggers dhcp port deletion but asynchronously,
therefore in the condition described in the bug report we may
get a conflict when deleting the segment too fast after the subnet.
Here we follow the example of how we auto-delete ports in net delete.
Please also find a fullstack test in Related-Change below.
Change-Id: Iba02f5a2211b18c2deb9097daad6be5e7d21faf8
Closes-Bug: #1878632
Related-Change: https://review.opendev.org/728904
(cherry picked from commit da45bbbff4)
New versions of isort broke pylint. This patch fixes it at 4.3.21.
Depends-On: https://review.opendev.org/739912
Change-Id: Ic6858b60ae6b7cd031843ea594b8fe1c8a67bb54
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry-picked from commit 75970c4cda)
In case when related dvr router is configured by L3 agent, it is first
added to the tasks queue and then processed as any other router hosted
on the L3 agent.
But if L3 agent will ask neutron server about details of such router,
it wasn't returned back as this router wasn't really scheduled to the
compute node which was asking for it. It was "only" related to some
other router scheduled to this compute node. Because of that router's
info wasn't found in reply from the neutron-server and L3 agent was
removing it from the compute node.
Now _get_router_ids_for_agent method from the l3_dvrscheduler_db module
will check router serviceable ports for each dvr router hosted on the
compute node and will then find all routers related to it. Thanks to
that it will return routers which are on the compute node only because
of other related routers scheduled to this host and such router will not
be deleted anymore.
Change-Id: I689d5135b7194475c846731d846ccf6b25b80b4a
Closes-Bug: #1884527
(cherry picked from commit 38286dbd2e)
There are several invalid cased that Rally ignored before and that will
become an validation error soon.
* transmitting None where dict is expected
* setting 'name' of entities. It is restricted thing, since rally
generates pseudo-random names that can be filtered by celanup
mechanism. Currently, Rally overrides 'name' params silently, but it
will become an error soon.
Change-Id: Icef60dc4db70a3058251909cf485cd8e8424cb16
(cherry picked from commit 98b326f0e4)
This option allows to configure Number of times nova or ironic client
should retry on any failed http call.
Default value for this new option is "3".
Change-Id: I795ee7ca729646be0411a1232bf218015c65010f
Closes-Bug: #1883712
(cherry picked from commit e94511cd25)
Change-Id: Id1ed2922a908148b2b271bd28cc974ef424530d5
Closes-Bug: #1882061
(cherry picked from commit 58d1d0dbdd)
(add newline in neutron/tests/unit/common/ovn/test_utils.py to resolve merge
conflict with https://review.opendev.org/#/c/738214/)
The ``neutron-ovn-db-sync-util`` replaces the ``ovn`` mechanism
driver with the ``ovn-sync`` mechanism driver. Subsequently it
makes calls into the OVN L3 service plugin.
At present the OVN L3 service plugin assumes the ``ovn`` mechanism
driver to be present and produces a Traceback when it is not.
This patch fixes that by testing for both of the supported
mechanism drivers.
Change-Id: I1ac685a12f49119f5ef1428cbc504b639d783803
Closes-Bug: #1882202
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
(cherry picked from commit 206ce24676)
Prior to this patch, if the [ovn]/enable_distributed_floating_ip
configuration option changed in an existing environment the OVN
driver wouldn't adapt to it requiring administrators to clear up the
"external_mac" column from the NAT table manually for the existing
floating ips.
With this patch, OVN will automatically correct existing NAT entries for
floating ips whenever this option changes.
To make the code simpler when handling the port up/down event this patch
always set the logical_port and the neutron:fip_external_mac key in the
external_ids column of the NAT entry when creating the floating ip.
Note that we are not using the maintenance task for this either, we are
re-using the event that set/unset the "external_mac" column for this
because, whenenver the service is restarted (after the configuration is
changed, we need to restart for it to take effect) the IDL will re-trigger
those events.
Closes-Bug: #1883559
Change-Id: I6a85fdde2558d781bf2853c5d11c5c964bbab81f
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry picked from commit 26f6b90930)
In some cases it may be useful to log new vlan tag which is found
on the port when it losts old vlan tag which should is expected to
be there.
So this patch adds such value to the log message.
TrivialFix
Change-Id: I231e624f460510decc6d2237040c8bef207e2e8e
(cherry picked from commit 3ac63422ea)
Block traffic between br-int and br-physical is over kill
and will at least
1. interrupt vlan flow during startup, and is particularly
so if dvr enabled
2. if let's rabbitmq is not stable, it is possible data plane
will be affected and vlan will never work.
Using openstack on k8s particularly amplifies the problem
because pod could be killed pretty easily by liveness
probes.
Change-Id: I51050c600ba7090fea71213687d94340bac0674a
Closes-Bug: #1869808
(cherry picked from commit 90212b12cd)
The need for this change stems from following issues:
1) When ovs_use_veth = False with ovs-dpdk issue with ovs
was observed - after vswitch restart interface is not comming up.
Meaning ovs-dpdk uses ovs internal ports and it is not able to bring
them up on restart.
2) When ovs_use_veth = True and ovs-dpkd is used, packets sent with
incorrect checksum due to the fact that ovs-dpdk does not do checksum
calculations for veth interface.
This commit allows to use second option and resolve checksum issue by
disabling checksum offload.
Closes-Bug: #1832021
Related-Bug: #1831935
Change-Id: Iecce8d2c6c2c46718cc1020c6e8f914cd4560e4b
(cherry picked from commit 11838a2bc5)
This patch is adding support for the router_availability_zone extension
for Neutron.
The OVN driver will now read from the router's availability_zone_hints
field and schedule the router ports onto OVN chassis belonging to those
AZs.
Since the OVN driver does not rely on the L3 agent, this patch does not
re-use the configuration option for the agent to configure the
availability zone that a Chassis belongs to (even because there's no
configuration file in nodes such as networker nodes). Instead, this
patch reuses the "ovn-cms-options" field from the local OVSDB to
configure the Chassis. The follow syntax has been used:
$ ovs-vsctl set Open_VSwitch .
external-ids:ovn-cms-options="enable-chassis-as-gw,availability-zones=az0:az1"
In the example above, the Chassis has been configured to belong to two
AZs: "az0" and "az1".
This patch also implements listing the availability zones:
$ openstack availability zone list
As well as validating the router's availability zone hints:
$ openstack router create --availability-zone-hint az0
--availability-zone-hint az1 test_router
The above command would fail if there's no "az0" and "az1" configured in
any OVN chassis.
Documentation for this feature is being written and will be submitted
in a separated patch.
Partial-Bug: #1881095
Change-Id: I4567f3d541d382b6432c1ab3d35276d81ce71d82
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry picked from commit d669dff1dc)
When retrieving a vacant L3 agent binding index, if
"is_manual_scheduling" is set, the method "get_vacant_binding_index"
should always return a valid binding index. If the existing binding
indexes are sequentially aligned, the method will return a new one
on top; if there is a gap in the binding indexes list, the first
free index will be returned.
Closes-Bug: #1884906
Change-Id: I0a89bca0734d3e735fb357e488f85589e81d709f
(cherry picked from commit 2bb514f2d7)
WHen retrieving a vacant DHCP agent binding index, if
"force_scheduling" is set, the method should return a valid binding
index. If the existing binding indexes are sequentially aligned,
the method will return a new one on top; if there is a gap in the
binding indexes list, the first free index will be returned.
Change-Id: Ib4cbeb7c9f0c1e959ad53570320610925ff3d88f
Closes-Bug: #1883513
(cherry picked from commit ed56429548)
Recent changes in some versions of iproute2 CLI output (v4.18),
have invalidated the regular expression used to parse the
"ip link" output.
To solve this problem and avoid future ones, pyroute2 is used to
retrieve the virtual functions information and set the VF attributes
(spoofcheck, min_tx_rate, max_tx_rate and link_state).
pyroute2 extended the "ip link" support to retrieve this information,
adding "ext_mask=1" in the get command. If no virtual functions are
present in this particular network interface, the added method,
"get_link_vfs", will return an empty list.
The set commands can return a "InterfaceOperationNotSupported" in
case the operation is not supported. For min_tx_rate, if the driver
does not support to set a minimum bandwidth, an "InvalidArgument"
(from a pyroute2.NetlinkError(22)) exception will be raised.
Conflicts:
neutron/tests/unit/agent/linux/test_ip_link_support.py
Change-Id: I680da4f64bd114f1caecaaeedbf8a4b1915a0849
Closes-Bug: #1878042
(cherry picked from commit c5d8fd6329)
The rate value is converted to bytes per second before being
sent to Pyroute2, but it used the wrong value for the calculations.
This resulted in incorrect rates.
It should be multiplied by 1000 (kbit), not 1024 (Kibit).
The same applies to the burst value (kb).
Change-Id: I70cb1fe651a50b2f6495d7a365a6beb2ba111c6d
Closes-Bug: #1884273
(cherry picked from commit 94d6e38fa0)
While the segments plugin is not loaded in neutron config, it should
be loaded anyways in OVN maintanance task, to operate on the first
default segment of each network.
Change-Id: Ideffacc2f478c95eeec881c82d1d5bae46ecdc74
Closes-Bug: 1883193
(cherry picked from commit 56f519f472)
Darragh O'Reilly
Zuul
Maciej Jozefczyk
Oliver Walsh
Jens Harbott
Bence Romsics
Lucas Alvares Gomes
Slawek Kaplonski
Andrey Kurilin
Frode Nordahl
shenjiatong
Alexander Vlasov
Rodolfo Alonso Hernandez
Weronika Sikora