This reverts commit 8e3bddbf8b.
Reason for revert:
As part of the reverted commit, the redirect-type=bridged flag was
enabled by default. However this have the side effect of also
decentralizing N/S traffic for geneve tenant networks, breaking the
VM connectivity on them when it must be centralized, i.e., when no
FIPs are associated to the VMs.
A new fix will be provided ASAP.
Change-Id: I30b1328b30f1b36b8b7ee556aa52ac6b2dd91d4e
The metadata port fixed IPs depend on the subnets "enabled_dhcp" flag.
If the subnet has this flag disabled, the metadata port doesn't receive
an IP on the subnet CIDR.
The method ``create_metadata_port`` should explicitly define what fixed
IPs should request the metadata port during the creating depending on
the subnets "enabled_dhcp" flag.
Closes-Bug: #2011724
Change-Id: If362fab20ac03f8b62471b60c031f9349171ce93
It is very wasteful to create a frozen row copy for every event
that we process. It can dramatically increase the time to process
the initial events from connecting to the database.
Closes-bug: #2011590
Change-Id: Ic4bf26d9b1f937073ddc6d0c3e9d22a777912ebf
Bug introduced by Ic3c147136549b17aea0fe78e930a41a5b33ab9d8, when a
VLAN mapping is not registered during a call to
update_network_segement, the function should return None.
Closes-Bug: #2009215
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: I91f8e8bd18d9956216e5715c658dfb408a2cbf07
The function is supposed to omit neutron_pg_drop Port_Group (as per its
docstring) but it actually returns it because of incorrect if-statement
structure.
The function is not used anywhere in the tree and hence doesn't affect
any feature, at least in master.
(It was used before I27af495f96a3ea88dd31345dbfb55f1be8faabd6.)
The function will be used in a consequent patch, so it now becomes
important to make it behave as documented.
Related-Bug: #2009053
Change-Id: I0c5d3db521131cc71135a9c787ed01479b451cfb
This patch partly reverts the workaround introduced at [1].
In patch [1] the reside-on-redirect-chassis was forced for vlan provider
networks to force centralized but not tunneled traffic for those
network. In this patch we are making use of the "redirect-type" flag
instead so that the traffic can be distributed and still not tunneled.
This flag needs to be set on the router gateway port (port connecting
the router to the external network) unlike the previous one that was set
on the router interface port (port connecting the (vlan) internal
network to the router). In this patch we are setting it on all ovn
gateway ports if DVR is enabled, as:
- It is needed for vlan (provider) network to have their traffic
distributed instead of tunneled to the controller where the cr-lrp is
associated
- It is not having any effect on the geneve tenant networks as it only
applies to network that has a localnet port associated to them.
[1] https://review.opendev.org/c/openstack/neutron/+/871252
Closes-Bug: #2003455
Change-Id: Ia05416df88904e864d4fc9760ffcdc97a4651f9f
This patch adds an extra checking to ensure the
"reside-on-redirect-chassis" is set to true for the logical
router port associated to vlan provider network despite having
the "ovn_distributed_floating_ip" enabled or not. This is needed
as there is an OVN bug [1] making it not work as expected.
Note setting this to true has implications as the traffic will be
centrallized (but not tunneled) through the node with the gateway
port.
The expected behavior of this flag, once [1] is fixed is:
- reside-on-redirect-chassis flag to False: means traffic goes
tunneled to the controller with the gateway port. Means it requires
extra MTU reduction to work.
- reside-on-redirect-chassis flag to True: means traffic is not
tunneled to the controller with the gateway port, but the traffic is
centralized through the controller with the gateway port. Thus it
does not require extra MTU reduction.
- reside-on-redirect-chassis to False, but with ovn-chassis-mac-mappings
configured: means the traffic is fully distributed and it is not being
tunneled, nor sent, through the controller with the gateway port. This
is the preferred option as it does not require MTU reduction and it
avoids the extra hop. However it is not working as expected, therefore
the fallback to set reside-on-redirect-chassis to True.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2162756
Closes-Bug: #2003455
Change-Id: I662cb30c842e54bb9f7dabac5519283aa7c7f8d0
A recent change [1] to show the real heartbeat timestamp from OVN agents
had a side effect of changing the timestamp format, which now includes a
timezone:
+-------------------+----------------------------------+
| Field | Value |
+-------------------+----------------------------------+
| last_heartbeat_at | 2023-02-23 14:12:07.471000+00:00 |
+-------------------+----------------------------------+
This unexpected format change causes some clients to fail to parse the
response to GET /v2.0/agents.
Normalise the format of the timestamp to remove timezone information.
Also remove the microsecond part, which was not done for OVN, but is
absent from other network agents.
[1] https://review.opendev.org/c/openstack/neutron/+/844179
Closes-Bug: #2008257
Change-Id: I75a37fb9b49a421e4524da6b56ef8362ceb6107b
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
In the method ``add_vnic_type_and_pb_capabilities_to_lsp``, if the port
binding profile is an empty string (or something that cannot be parsed
by jsonutils), skip this port.
Closes-Bug: #2006112
Change-Id: Ifa8956bf1c5eb9b6c3214638ac4e5b7f10e4cf74
This new method retrieves the config option "rpc_workers" from the
configuration. If this option is not loaded, the method registers
the ``neutron.conf.service.SERVICE_OPTS`` options before reading
the knob again.
Closes-Bug: #2004656
Related-Bug: #1889737
Change-Id: I1f99cb32f33cc91141136cb4e3fbd33715530c59
While other SQL engines can compare interger and boolean types,
PostgreSQL needs explicit casting to compare variables. Method
"_sync_subnet_dhcp_options" is currently raising the following
error:
operator does not exist: boolean = integer
Closes-Bug: #2004581
Change-Id: I715029c311c4516f3212054c5c72533b12fd0986
The from_self() method in SQLAlchemy is currently
being considered for removal from the library,
with a deprecation phase throughout 1.4 and then
removal by SQLAlchemy 2.0.
The from_self() method takes an ORM query object,
turns it into a subquery, then returns a new query
object that will SELECT from that subquery, while transparently
altering subsequent criteria added to the query to
be stated in terms of the subquery. The current
design direction of SQLAlchemy hopes to
de-emphasize the "transparently altering criteria"
part of the above use case, and to move users towards a
more explicit and model of usage where a subquery should
be created and used explicitly using the aliased()
construct, which is now very mature and can be used in ways
that were not available when from_self() was first introduced.
On the SQLAlchemy side, from_self() has proven to be one
of the most difficult features to maintain and test
as it can easily lead to extremely complicated scenarios, and
while I am also experimenting with some alternatives that
may still retain some of the "automatic translation" features,
those features are still proving to add similar internal
complexity which is having me lean towards the original
plan of removing open-ended "entity translation" features
like that of from_self() at least through the start
of the 2.0 series.
A code search for all of Openstack shows that the
two files modified here are the only usages of the
from_self() method throughout all of searchable Openstack
code. This speaks to the general obscurity of this method,
although neutron's Subnet code is actually using this
method as intended. The new approach necessarily changes
some of the method signatures here so that the explicit
"subquery" entity can be passed; code searches again
show that these methods are not being called anywhere
outside, so the query_filter_service_subnets method
becomes the private _query_entity_service_subnets method.
References: https://github.com/sqlalchemy/sqlalchemy/issues/5368
Closes-Bug: #2004263
Change-Id: Icec998873221ac8e6a1566a157b2044c1f6cd7f3
This patch adds config option to let cloud operator to disable
'stateful-security-group' API extension if OVN < 21.06 is used. This is
the case e.g. on Ubuntu 20.04 where OVN 20.03 is provided.
In case when API extension is enabled and OVN < 21.06 is used, Neutron
will fallback to stateful ACLs even for stateless security groups which
may be confusing for Neutron API users.
This needs to be done with config option and not by checking
automatically in OVN if "allow-stateless" is supported keyword for ACL's
action because it needs to be done during initialization of plugin,
where IDL isn't initialized yet and it would cause deadlock when Neutron
would try to connect to the OVN NB.
Closes-Bug: #2003999
Change-Id: I62e77dad2782e9c546745e860fda7622a8281739
notify() is called from python-ovs code which is not built to
recover from an exception in this user-overriden code. If there
is an exception (e.g. the DB server is down when we process
the hash ring), this exception can cause an unrecoverable error
in processing OVSDB messages, rendering the neutron worker useless.
Change-Id: I5f703d82175d71a222c76df37a82b5ccad890d14
This patch introduces the new OVN Neutron Agent definition in the
OVN agent list and creates a new class ``OVNNeutronAgent``.
Related-Bug: #1998608
Change-Id: I57de801473fc30f06acf1bc8a65cb2ff76b2954a
In order to decide if a port is a hardware offloaded port by just
reading the OVN Logical_Switch_Port register, it is needed the
VNIC type and the binding profile cababilities.
The maintenance task will only update those LSP ports that belong
to direct Neutron ports to avoid an unnecessary database load.
Related-Bug: #1998608
Change-Id: I5febe9d3eeef6c5b5f6d972b9e8ebfef541458ac
Before this patch, if a OVN router was associated with an
external network whose subnet had an empty `gateway_ip`, a
default route with an empty dst-ip is created in the OVN
database.
As documented in the Neutron API [0], it is allowed to create
a subnet without a gateway_ip.
0: https://docs.openstack.org/api-ref/network/v2/index.html?expanded=create-subnet-detail#create-subnet
Closes-Bug: #2002993
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: Ica76e0821d753af883444d2a449283e9e69ba03f
rpc_workers can be set < 1 with 'ovn' backend when no
other agent is running apart from ovn agents to
consume these rpc notifications.
Add and apply disable_notifications decorator on
methods which do rpc cast calls to agents, the
decorator makes the caller method execute only
when rpc_workers >=1. This patch not changing
default behavior and utilizes the rpc_workers config option
to enable rpc notification on resources updates only when
rpc_workers >= 1.
Also set rpc_workers=0 in ovn jobs to cover this scenario.
Closes-Bug: #1889737
Closes-Bug: #1992352
Change-Id: I700fe2cd422bc1eb8b5144ec116e7f0a60238419
This patch adds support for QoS minimum bandwidth rules in tunnelled
networks. Now the ML2/OVS and ML2/OVN mechanism drivers can represent
in the Placement API the available bandwidth of the tunnelled networks
in each compute host.
Both mechanism drivers represent the compute VTEP (VXLAN) or TEP
(Geneve) interface as an IP address. This new resource provider
(by default called "rp_tunnelled") represents the available bandwidth
of this interface. Any new port created in a compute node that belongs
to a tunnelled network, will request to the Placement API the
corresponding bandwidth from the resource provider inventory.
This patch does not provide backend enforcement support for minimum
bandwidth rules.
RFE spec: https://review.opendev.org/c/openstack/neutron-specs/+/860859
What is missing and will be added in next patches:
* Tempest tests, that will be pushed to the corresponding repository.
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/863880
Partial-Bug: #1991965
Related-Bug: #1578989
Change-Id: I3bfc2c0f9566bcc6861ca91339e32257ea92c7e9
Running with a stricter .pylintrc generates a lot of
C0330 warnings (hanging/continued indentation). Fix
some remaining ones in miscellaneous directories.
Also cleanup any remaining code that I missed in this
series, or has changed since I started.
Trivialfix
Change-Id: I17b4779020a7bfb369c3e721ab6638cd4a6ab50c
Port arp_spoofing_protection will install flows like this:
table=0, priority=9,in_port=2 actions=goto_table:25
table=25, priority=2,in_port=2,dl_src=fa:16:3e:54:f0:71 actions=goto_table:60
For network ports or port_security_enabled = False, those flows
will be delete by setup_arp_spoofing_protection in _bind_devices.
But the delete actions are a bit rough because it will delete any
flows with "table=0 in_port=2" and "table=25 in_port=2".
Besides, the ovs_agent extension handle_port will be run before
these actions [5]. So network or no security ports, if any flows
added by agent extesnion in table=0 with "in_port=2" will be delete
unexpectedly. Which also means any flows added before this call of
"uninstall_flows(table=0, in_port=2)" will be deleted.
This patch changes the uninstall flows to strict mode. Let it
delete the arp_spoofing_protection related flows only by verifying
the priority.
Closes-Bug: #2000046
Change-Id: Ifdd47b2ce8610e4b4b527fc3279e0bd7a8b21a1d
The previous `getattr(old, 'nb_cfg', False)` would evaluate to `False`
if the `old` row either did not contain a `nb_cfg` value or if the value
was 0.
As 0 is the value set on startup of the ovn-controller this causes the
neutron-api to ignore any event a ovn-controller directly sends after
startup. In turn this causes us to miss the information that the agent
is synchronized, causing the agent to appear as down, until something
bumps the `nb_cfg` value globally.
Closes-Bug: #1997982
Change-Id: Icec8fee93e64b871999f38674e305238e9705fd4
Zuul
yatinkarel