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.
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.
Bug introduced by Ic3c147136549b17aea0fe78e930a41a5b33ab9d8, when a
VLAN mapping is not registered during a call to
update_network_segement, the function should return None.
Signed-off-by: Sahid Orentino Ferdjaoui <email@example.com>
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
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.
This patch partly reverts the workaround introduced at .
In patch  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
- 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.
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  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
The expected behavior of this flag, once  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.
A recent change  to show the real heartbeat timestamp from OVN agents
had a side effect of changing the timestamp format, which now includes a
| 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.
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.
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.
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
operator does not exist: boolean = integer
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.
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.
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.
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.
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
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.
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.
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 . 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 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
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.
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
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,
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.
Signed-off-by: Arnaud Morin <firstname.lastname@example.org>
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
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.
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.
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.
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,
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
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").
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.