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
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
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
During the OVN DB inconsistency check, a OVN LSP could not be present
in the Neutron DB. In this case, continue processing other LSPs and
let other ``DBInconsistenciesPeriodics`` methods to resolve this
issue.
Closes-Bug: #1999517
Change-Id: Ifb8bdccf6819f7f8af1abd3b82ccb1cd2e4c2fb8
When libvirt (nova) detach a port on OVS bridge, two events are sent:
* one event with 2 actions "old" and "new": a change on ofport (from a
regular value to -1)
* a second event with action "delete"
If, for some reason, the second event is delayed, the rpc_loop iteration
will consider this port as "updated" instead of "deleted".
But, because ofport == -1, the port update will be discarded, and
finally removed from port_info["current"].
As a result, on next iteration, the deletion wont be performed.
Most of the time, we endup with some leftovers (like openflow rules,
etc.)
The purpose of this patch is very simple, when looping over ports in
_get_ofport_moves, we will discards the ports that have ofport == -1, so
the port will not be considered as updated and next iteration will be
able to delete it correctly.
Closes-Bug: #1992109
Change-Id: Ib4a7183867e1b21810b6915a475a234278bf884c
Signed-off-by: Arnaud Morin <arnaud.morin@ovhcloud.com>
The "ChassisBandwidthConfigEvent" event registration is now done in the
"OvnSbIdl" class initialization. That ensures this event is registered
in a worker thread.
If the event is called before the "OVNMechanismDriver"'s "OVNClient"
has been instantiated, the event is skipped. When the OVN placement
extension is loaded, all chassis configurations are read and loaded,
thus any previous event is not relevant.
This patch also adds a "match_fn" check to
"ChassisBandwidthConfigEvent". If during an update event, the bandwidth
options are not modified, this class does not update the resource
provider inventories.
Closes-Bug: #1998108
Related-Bug: #1578989
Change-Id: I74883041c642b9498299ebf2b5bf885776e241e0
To be able to filter on the address scope of the ports in the
ovn-bgp-agent we add the address scope of the subnet pool to
each LSP port in the northbound. Northd writes it to the
southbound so the ovn-bgp-agent has access to it. The
ovn-bgp-agent talks directly to the southbound to announce
the networks via BGP that match the configured address scope.
Change-Id: Ieb4cab11068747bd79868c6eb1778aab91447c30
Closes-Bug: #1996741
MechanismDriverContext has an attribute _plugin_context, which carries
the current context with it. This is used by many ml2 drivers, as it is
the only way for them to get the current context. We now make this a
public API by adding a property to MechanismDriverContext that returns
_plugin_context as a read-only attribute.
Change-Id: If9b05655286f42081cf26c90c563429ca2e63244
Add a Singleton meter ID Generator for both bandwidth limit
and packet rate limit, because for one bridge the meter ID
is a sharing range.
Closes-Bug: #1964342
Change-Id: Ibb9762d57913ea701dcf2746a0e0db74c6a7ca01
The table "router_extra_attributes" is a child of "router" table.
Each register contains extra information that completes the router
description. When using ML2/OVS mechanism driver, the methods that
create and populate the "router_extra_attributes" register are always
called from the L3 DVR, L3 HA and availability zones extensions.
When using ML2/OVN, those extensions are not loaded and therefore the
"router_extra_attributes" register is not created.
Despite this register is currently not used in ML2/OVN (it will be in
future features), there are some project expecting the
"router_extra_attributes" register to be always created (for example,
neutron-dynamic-routing [1]).
This patch enforces the child register creating always when a router is
created. This register is populated with the default values. This new
register does not affect any current operation related to ML2/OVN nor
ML2/OVS.
There is a 1:1 relationship between "routers" and
"router_extra_attributes". The child register is deleted by the database
engine when the "routers" register is deleted (ondelete="CASCADE").
[1]https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/863713
Closes-Bug: #1995974
Change-Id: Ic546e40513402fa101c9687acce382cd6b84356c
In the maintenance task, the method that fixes the missing or not
updated resources ``DBInconsistenciesPeriodics._fix_create_update``
not won't exit if the resource is not found in the Neutron database.
When the OVN revision number is bumped, now the method retrieves the
resource standard attributes register. If this register does not
exist, that means the resource has been deleted.
The method catches the ``StandardAttributeIDNotFound`` exception and
logs an error.
Closes-Bug: #1996180
Change-Id: Ic47c10ea2ba07347f32f75aa5de3c69e9e261780
Running with a stricter .pylintrc generates a lot of
C0330 warnings (hanging/continued indentation). Fix
the ones in neutron/plugins.
Trivialfix
Change-Id: Id9138652f5f07ef12fa682e182fe210019e8f975
Zuul