Since [1], "get_subnet_dhcp_options" returns always a dictionary
in "subnet" instead of None. This patch checks not only that "subnet"
is None but also the dictionary is not empty.
[1]https://review.opendev.org/c/openstack/neutron/+/807692
Closes-Bug: #1948466
Change-Id: Ie93cf3e47e09b3e5051be1ffad512251775b0492
(cherry picked from commit 95c2801da8)
Fixes [1] and [2] for bug [3] are using new callabacks mechanism and
expects payload as one of the arguments passed to the callback functions.
This works fine in Xena+ releases but not in Wallaby and olders where
old callbacks mechanism is still used, at least for the security group
AFTER_DELETE events.
So this patch fixes that by changing to the old callbacks mechanism in
the logging service plugin in stable/wallaby and older branches only.
Closes-Bug: #1955546
[1] https://review.opendev.org/c/openstack/neutron/+/804237
[2] https://review.opendev.org/c/openstack/neutron/+/812459
[3] https://bugs.launchpad.net/neutron/+bug/1939558
Change-Id: I0003bd566dc769436ad1342351ad058394bd52da
Make sure we pass integer values to ovs when configuring bandwidth
limit. This was likely working properly with Python2, and we may have
missed this when migrating to Python3:
https://www.python.org/dev/peps/pep-0238/
Change-Id: I2f8d974d6644657aea95302d94ca0095d70a7e62
Closes-Bug: #1936839
Co-Authored-By: Tamás Trásy <tamas.trasy@ericsson.com>
(cherry picked from commit 8261b67b6e)
(cherry picked from commit 38551777e0)
(cherry picked from commit 82e2a3d362)
"LoggingPlugin._clean_logs_by_resource_id" method receives PORT,
AFTER_DELETE events, in the old format (not using payloads but
kwargs). New implementation was added in Xena release.
Closes-Bug: #1954666
Change-Id: I736fef3a10bc2887efb26c95e9fc1eea14969ccf
(cherry picked from commit aaa0e99bac)
There are two types of OF rules in TRANSIENT_TABLE:
- With priority 100: these rules match by "in_port", that is a
unique identifier.
- With priority 90: these rules match by MAC address and VLAN ID.
This combination (MAC, VLAN) is unique.
That means when a deleting an OF rule in TRANSIENT_TABLE, it is
enough to specify the "in_port" or the (MAC, VLAN) tuple. The
"--strict" parameter, added to also define the priority, is not
needed.
By removing the "--strict" parameter, these deletion commands can
be executed synchronously at the end of the OVS deferred context,
when all the OF rule commands (addition or deletion), are executed
at the same time. That removes the small window, detected in the
related bug, when the OF rule set for a port is not complete.
Closes-Bug: #1952770
Change-Id: I9f5bd8a1404dde3a0aa163ce72aef2961f537676
(cherry picked from commit ef7f673098)
OVN Driver currently fixes gateway_mtu MTU to the provider MTU value
without considering if the private networks in the associated router
have greater MTU values than the provider. This is unnecesary and
adds extra actions for each packet. This patch fixes that, as now
gateway_mtu is only set in case the provider MTU is smaller than the
private MTU.
The changes in create_router_port and delete_router_port were necessary
as there could be a use case when the user first sets the gateway
router and later adds subnets from networks with greater MTU, so this
parameter needs to be checked after adding a subnet.
Closes-Bug: #1951559
Signed-off-by: Elvira García <egarciar@redhat.com>
Change-Id: If56f1a3dcdc8c57303d5641df79ea919ba7c170d
(cherry picked from commit 0725533a6f)
The OVS Firewall has a singleton class that manages the conjuction IDs
to used in the OF rules. Those conjuntions are used to group rules
related to remote security group IDs.
Now each time the OVS agent is started, the OVS Firewall initial
conjunction ID is calculated based on the present OF rules. This value
and the next one used won't clash with any present rule in the
integration bridge during the initial transient period.
Related-Bug: #1934917
Change-Id: Ie2e4441f766947a2164dec2d1555c7049428903f
(cherry picked from commit 0634dcc6d0)
Today, we invoke ovsdb-client to cleanup the MAC_Binding entries
without specifying any timeout. This can lead to workers blocking
forever if there's an issue with the connection to the server.
This patch is adding a timeout parameter to the command line to
prevent this condition.
Closes-Bug: #1948891
Related-Bug: #1946318
Conflicts:
neutron/tests/unit/plugins/ml2/drivers/ovn/mech_driver/test_mech_driver.py
Signed-off-by: Daniel Alvarez Sanchez <dalvarez@redhat.com>
Change-Id: Id393cbec31dd64a795e85d756b7b843c9dfc59f3
(cherry picked from commit 7874c57601)
The patch filters columns from OVN DB only to those that are used by the
ovn mechanism driver. It means generated ACLs from Neutron DB and ACLs
obtained from the OVN DB will always have the same columns. This is
useful for db sync script when comparing if given security group rule
has corresponding ACL in the OVN DB.
Closes-Bug: #1951296
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
Change-Id: I39e3b987b8546fd970a933b846ed23c8a2588258
(cherry picked from commit 23b99e2f12)
In "test_restart_rpc_on_sighup_multiple_workers", the test needs to
wait until the RPC workers have been properly launched by
``oslo_service.service.ProcessLauncher.launch_service``. Once this
method returns, it is guaranteed that the child worker processes
are running and the signal process handlers are attending the
SIGHUP signal that will reset them.
Closes-Bug: #1938428
Change-Id: I1dc56092d099223accc3aefa8e303310c4f6787e
(cherry picked from commit fafcabdbe0)
When an interface is moved to a new namespace, specially with OVS
internal ports, the interface first dissapears from any network
namespace and then is added again. ovs-vswitchd service detects
this interface change as reported in [1]. This delay is the cause
of the related bug, where some interfaces are not present when
the L3 agent needs to manipulate them.
[1]https://bugs.launchpad.net/neutron/+bug/1948832/comments/3
Conflicts:
neutron/tests/functional/agent/linux/test_ip_lib.py
Closes-Bug: #1948832
Change-Id: I3af4d0afa784899689ccb595ce6ba64495431eb9
(cherry picked from commit ebc4766990)
(cherry picked from commit 9c41365041)
In the _process_added_router() method of the L3 agent, if processing
router will fail, router_info should be cleaned to e.g. be removed from
the router cache so it will not be treated as updated router in next
iteration of the agent.
Conflicts:
neutron/agent/l3/agent.py
Closes-Bug: #1947993
Change-Id: Ic0bc3d951d32efadc116708bfe518a711730429d
(cherry picked from commit 41159bd9a4)
(cherry picked from commit 1c17019f6c)
This is follow up of the patch [1] which fixed updating MTU in the
snat namespace for the DVR routers.
In case of DVR-HA routers there was additional issue with that as
L3 agent tried to update MTU for the qr- interface in the
self.ha_namespace which, for DVR-HA routers is snat namespace.
This patch fixes that issue by setting MTU on the qr- interface in
qrouter namespace and also setting MTU on the snat interface in snat
namespace.
[1] https://review.opendev.org/c/openstack/neutron/+/799226
Conflicts:
neutron/tests/functional/agent/l3/test_dvr_router.py
Closes-bug: #1933273
Change-Id: I409bc674b65e4f495ebd42d03e97a09d51482339
(cherry picked from commit 21eabbcf03)
To check the existance of a namespace, instead of listing the
namespaces directory (by default "/var/run/netns"), this patch
directly checks the existence of the namespace directory, using
"os.path.exists".
This check is faster than listing the whole directory and avoids
timeout problems as reported in the related bug.
Conflicts:
neutron/privileged/agent/linux/utils.py
Closes-Bug: #1947974
Change-Id: I558d50d28378beb3710d98a2113ff9549c82ae17
(cherry picked from commit 8127221479)
(cherry picked from commit 6a9c05a924)
Setting new controller for bridge every time when neutron-ovs-agent
is restarted or is doing full-sync may cause some short data plane
connectivity loss and is not needed if same controller is already
configured for the bridge.
With this patch neutron-ovs-agent will first check if controller is
configured for the bridge and if it's the same as what should be
configured, it will skip setting it up.
With this patch also protocols added to the bridge will be first checked
if they aren't already there and only missing ones will be added if
necessary.
Setting of the connectivity mode and inactivity probe is
always performed as this don't cause connectivity issues and is cheap
so we can always ensure that those parameters are configured properly.
Conflicts:
neutron/agent/common/ovs_lib.py
neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/ovs_bridge.py
neutron/tests/unit/plugins/ml2/drivers/openvswitch/agent/openflow/native/ovs_bridge_test_base.py
Closes-Bug: #1948642
Change-Id: Idfa763df8c60d8ae46cd6351d1b6dc7d950b4c67
(cherry picked from commit 11d166be68)
(cherry picked from commit b1eccf5a2d)
Currently workload VMs start before subnet is connected to router.
When DVR is enabled this causes sometimes that one of the VMs is not
able to get metadata.
Closes bug: #1947547
Change-Id: Ifd686d7ff452abd1226fbbc97f499e05102e4596
(cherry picked from commit d49ce1652d)
The MAC_Binding table in the SB database may grow indefinitely (due
to a lack of an aging mechanism of its entries) and eventually
lead to OOM killers for neutron-server which maintains an in-memory
copy of the database.
In order to stop monitoring this table, this patch is invoking
the ovsdb-client tool to remove the entries associated to
Floating IPs that have just been detached. The execution of this
tool is really fast as it will just invoke a JSON-RPC transact command
which doesn't require downloading the database contents.
In a scale test, the memory consumption of neutron-server dropped
from 75GB to 7GB with this patch.
Closes-Bug: #1946318
Conflicts:
neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py
neutron/tests/functional/plugins/ml2/drivers/ovn/mech_driver/ovsdb/test_ovsdb_monitor.py
neutron/tests/unit/plugins/ml2/drivers/ovn/mech_driver/test_mech_driver.py
Note: The functional test has been changed for this stable branch
because the update_tables() method from ovsdbapp is not availabie for
this version of Neutron. So I changed the functional test to add the
MAC_Binding entry via ovsdb-client instead of using ovsdbapp to do so.
Signed-off-by: Daniel Alvarez Sanchez <dalvarez@redhat.com>
Change-Id: Id84bf17953527c415d611bfc198038fb6f811de3
(cherry picked from commit f6c3552769)
After migration from ML2/OVS to ML2/OVN trunk subports which were created
by the neutron-ovs-agent to connect br-int with trunk bridges (tbr-)
aren't needed anymore and should be deleted.
Closes-Bug: #1946479
Change-Id: Ib1e3b78597ebdde1aa9d2b242e2005a05a7db89f
(cherry picked from commit bf6831e0d2)
NOTE: this patch is an ammend of [1].
When a SG or a port is deleted, the related log entry should be
too. A log entry has the following fields:
- log.resource_id = SG ID
- log.target_id = port ID
[1] was deleting all log entries, related or not with the SG ID
deleted. This is because "get_logs_bound_sg" returned all log entries,
including those ones without any "resource_id" or "target_id".
Now this method can return only the log entries related to a port or
a SG, excluding those ones without those two parameters populated.
Closes-Bug: #1939558
[1]https://review.opendev.org/c/openstack/neutron/+/804237
Conflicts:
neutron/tests/unit/services/logapi/test_logging_plugin.py
Change-Id: Icb92327a06486e168ce064532d819347e6031cc1
(cherry picked from commit 41f78c678b)
(cherry picked from commit 2c4ab468ae)
(cherry picked from commit d5fd9f035a)
(cherry picked from commit 7790cecfc8)
After migration from ML2/OVS to ML2/OVN tap ports which were created
by the DHCP agents and router ports (like e.g. qr- or qg-) which were
created by the L3 agents aren't needed at all and should be deleted.
Previously those ports were set to be DOWN only. With this patch
all such ports will be simply deleted from the openvswitch.
Related-bug: #1946479
Change-Id: I74cd5820389c86819c6884d3d61c9b2f7907cc88
(cherry picked from commit 5092f3fb98)
In order to avoid having a MAC_Binding table explosion and helping
lowering the memory footprint when using ML2/OVN this patch is setting
two options to the OVN routers:
* always_learn_from_arp_request: By setting this to False we
avoid learning from ARP replies observed in the network. Only the
ARP requests sent by OVN will generate a MAC_Binding entry in the
OVSDB database. For larger broadcasts domains this avoids having a
MAC_Binding table explosion, reduce the DB size and memory footprint
of ML2/OVN.
* dynamic_neigh_routers: By setting this to True we avoid
pre-populating flows for router to router communication, reduding
the number of flows, DB size and memory footprint of ML2/OVN.
For more information on these option for core OVN please refer to:
https://www.ovn.org/support/dist-docs/ovn-nb.5.html
This patch also includes a new maintenance task to include these options
to existing routers in the system.
Related-Bug: #1946318
Change-Id: I056acdec9b6ee2341d2bc4f7bd9a678f3bf91972
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(cherry picked from commit a278c5ba78)
Always update the DHCP options when the metadata port is created,
updated or deleted. If the metadata port IP addresses are updated,
the DHCP options register should be too, modifying the static routes
defined in "DHCP_Options.options.classless_static_route".
These static routes will be injected in the VM in the DHCP request.
The IP address of the metadata port should match with the static
route redirecting the traffic to the metadata IP address
"169.254.169.254/32":
$ ip r
default via 10.0.0.1 dev eth0
10.0.0.0/28 dev eth0 scope link src 10.0.0.7
169.254.169.254 via 10.0.0.2 dev eth0 # 10.0.0.2 is the metadata
# port IP address
Conflicts:
neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py
neutron/tests/functional/plugins/ml2/drivers/ovn/mech_driver/test_mech_driver.py
neutron/tests/unit/fake_resources.py
Closes-Bug: #1942794
Change-Id: Id5d4909caa521a899b97d83bdc1963b010e97dac
(cherry picked from commit bd0ded15ca)
(cherry picked from commit 7efce62b4f)
(cherry picked from commit f4dd0b80ac)
When network's MTU is changed, Neutron sends notification about it
to the L3 agents. In case of DVR (and DVR HA) MTU is then changed in
the qrouter- namespace but should be also changed on snat interfaces
in the snat namespace. And that part was missing.
This patch adds special implementation of the internal_network_updated()
method in the DvrEdgeRouter class so it can configure MTU also for
in the snat namespace.
This patch also removed passing attributes "interface_name",
"ip_cidrs" and "mtu" to the internal_network_updated() method and adds
"port" dict to be passed there. It is consistent with what is already
done in e.g. internal_network_added() method and "port" dict is actually
necessary to configure properly snat internal interface in the snat
namespace.
This patch adds also functional test of update network mtu for all types
of routers as there was no such test at all.
There is additional issue with DVR-HA which isn't fixed with that patch
and for which follow up will be proposed. Because of that this patch is
marked as partial fix for the related bug.
Conflicts:
neutron/tests/functional/agent/l3/test_dvr_router.py
Related-Bug: #1933273
Change-Id: I200acfcaaae7f056ea9a563fead9ff2de8464971
(cherry picked from commit b5dd6efdca)
Log the results of the Ansible playbooks by default so that it is easier
to go through them later in case there's something unexpected. The log
is located in $HOME instead of /var/log/ to avoid the need of privileges.
Signed-off-by: Elvira García <egarciar@redhat.com>
Change-Id: Ida2fc11f28200030fff9ddf1e56fc442a2016bab
(cherry picked from commit 744e906f87)
Zuul