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.
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 <firstname.lastname@example.org>
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.
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.
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.
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.
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.