This reverts commit 66ac943b6435901c163c3050ad41dfcaf36ac11d.
Reason for revert: After discussions with the core reviewers for ML2/OVN
and Neutron folks about this configuration option we understood that we
should just enable RpcWorkers to connect to the OVN database by default
and later allow rpc_workers to be set to 0 in Neutron (for those looking
for optimizations and that don't need RpcWorkers in their deployment). So
I am proposing a revert for this configuration option.
Change-Id: I73ba195401fff9f832b84633398816383f710b23
This patch changes the policy for updating routes to support ECMP,
and will now add ECMP routes to the Neutron router namespace when
there are multiple routes pointing to the same destination address.
Change-Id: I842c1408ee0235bc54441e9ed69c8b87ea30651b
Related-Bug: #1880532
This patch sanitizes the MAC address coming from a user input:
- The "base_mac" address configuration parameter.
- The "port.mac_address" stored in the database, if the script
provided is not executed.
This patch relays on [1], that will sanitize any input coming from
the server API.
This patch adds a new script to sanitize all "port.mac_address"
registers stored in the dabatabase.
[1]https://review.opendev.org/c/openstack/neutron-lib/+/788300
Related-Bug: #1926273
Change-Id: I8572906cc435feda1f82263fd94dda47fc1526e1
This adds a middleware for noauth that would inject a fake
project_id for create requests. This would ensure that api
consumers don't have to provide a fake project_id in requests.
Closes-Bug: #1934039
Change-Id: I5e1de571034be41f1147c130fce66e6cf70b1369
Previously if extension was not supported by one of the mech drivers,
but it wasn't filtered out by next mech driver, it was available finally
in the list.
Now, this patch changes that so if extension is disabled by one of the
drivers it isn't available on the list at all.
This will work better e.g. with discoverability of what is available
e.g. when OVN backend is used by Neutron.
Closes-Bug: #1929676
Change-Id: I6a4ff42f47f7ee90365516d37472c09ac87773e5
When the router GW interface is updated or deleted, the routes should
be checked in other to prove all of them have connectivity to any of
the router interface subnets.
In a router, all routes nexthops must have connectivity with one
interface subnet. If not, this route cannot send the packets to this
route gateway; therefore this route becomes invalid.
Closes-Bug: #1925368
Change-Id: I7ce93b863b0dc0d4a2376fcfd602d2facb6fb2d0
Add a new ovs agent extension to support distributed DHCP for
VMs in compute nodes directly. For large scale deployment, this
can be used to reduce the number of neutron agents. Large scale
cloud can benefit from it.
From the perspective of virtual machine, this will reduce the
probability of DHCP request failure. The VMs will get a higher
level availability for DHCP R/R, no single point of failure
permanently. If one host goes down, VMs in other hosts will not
be influnced by it.
For the perspective of network performance, after using this
extension, the DHCP broadcasting packages will be limited
to the host locally.
Partially-Implements: bp/distributed-dhcp-for-ml2-ovs
Closes-Bug: #1900934
Change-Id: Id8a4c501daad7c2185e6d69441182666ef987e61
Add a configuration option to ovn group:
additional_worker_classes_with_ovn_idl
to optionally enable OVN IDL connections on additional workers.
By default the IDL connections are only initialized on API and
maintenance workers as other worker types normally don't need them.
But some plugins or extensions might still require IDL connections on
other workers and now may enable them via configuration, by adding the
worker class (or its alias from neutron.worker_classes) to
additional_worker_classes_with_ovn_idl.
Closes-Bug: #1927977
Change-Id: Ia0d882220cd281e3c91648e3f32a842d61a5f57d
This change ensures that neutron relies on the same logic as libvirt
to generate hypervisor hostname, to fix imcompatible hostname format
used in Nova and Neutron for resource provider name in some
configuration pattens like the one generated by TripleO.
Closes-Bug: #1926693
Change-Id: Iea2533f4c52935b4ecda9ec22fb619c131febfa1
Map OpenStack SG stateful=False to OVN ACL allow-stateless action verb.
The verb is added in the latest OVN release, 21.06. Inspect db schema to
determine if the new action is supported by OVN before trying to create
it. Fall back to allow-related when it's not supported yet.
Also-Needs: I7343fb609fab91c20490842378747f7265241e82
This will require ovsdbapp version bump with the patch mentioned above
to make it work.
Change-Id: Ic1c36fb71a9d03e8697583a1ea9453d4c0052f74
When needing to create a point to point connection via a subnet,
generally and /31 is the recommended cidr. Neutron supports /31
disabling dhcp and gateway on a subnet. /32 is also supported in
openstack.
Closes-Bug: #1580927
Change-Id: I3bfa3efb9fb8076656b16c89d2f35d74efde12b7
SR-IOV agent can handle ports with same MAC address (located in
different networks). The agent can retrieve, from the system, the
MAC address and the PCI slot; because the PCI slot is unique per
port in the same host, this parameter is used to match with the
Neutron port ID stored in the database (published via RPC).
RPC API bumped to version 1.9.
Closes-Bug: #1791159
Change-Id: Id8c3e0485bebc55c778ecaadaabca1c28ec56205
This new quota driver, ``DbQuotaNoLockDriver``, does not create a lock
per (resource, project_id) but retrieves the instant (resource,
project_id) usage and the current (resource, project_id) reservations.
If the requested number of resources fit the available quota, a new
``Reservation`` register is created with the amount of units requested.
All those operations are done inside a DB transaction context. That
means the amount of resources and reservations is guaranteed inside
this transaction (depending on the DB backend isolation level defined)
and the new reservation created will not clash with other DB transation.
That will guarantee the number of resources and instant reservations
never exceed the quota limits defined for this (resource, project_id).
NOTES:
- This change tries to be as unobtrusive as possible. The new driver
uses the same ``DbQuotaDriver`` dabatase tables (except for
``QuotaUsage``) and the same Quota engine API, located in
``neutron.quota``. However, the Quota engine resources implements some
particular API actions like "dirty", that are not used in the new
driver.
- The Pecan Quota enforcement hooks,
``neutron.pecan_wgsi.hooks.quota_enforcement``, execute actions like
"resync", "mark_resources_dirty" or "set_resources_dirty", that has
no meaning in the new driver.
- The isolation between the Quota engine and the Pecan hook, and the
driver itself is not clearly defined. A refactor of the Quota engine,
Quota service, Quota drivers and a common API between the driver and
the engine is needed.
- If ``DbQuotaDriver`` is deprecated, ``CountableResource`` and
``TrackedResource`` will be joined in a single class. This resource
class will have a count method (countable) or a hard dependency on a
database table (tracked resource). The only difference will be the
"count" method implementation.
Closes-Bug: #1926787
Change-Id: I4f98c6fcd781459fd7150aff426d19c7fdfa98c1
Currently neutron uses socket.gethostname() to determine hypervisor
names, but this implementation is not fully compatible with libvirt
driver which uses canonical name for hypervisor name.
This incompatibility causes an issue with root resource provider
detection if a deployment uses FQDNs as canonicanl names.
This change introduces the resource_provider_default_hypervisor option,
so that users can override the hypervisor name by the single option(*1)
instead of setting two list options(*2). This is especially useful if
the deployment has multiple bridges or interfaces.
(*1)
[OVS]
resource_provider_bandwidths=br-data1:1024:1024,br-data2:1024:1024,\
br-data3:1024,1024,br-data4,1024:1024
resource_provider_default_hypervisor=compute0.mydomain
(*2)
[OVS]
resource_provider_bandwidths=br-data1:1024:1024,br-data2:1024:1024,\
br-data3:1024,1024,br-data4,1024:1024
resource_provider_hypervisors=br-data1:compute0.mydomain,br-data2:\
compute0.mydomain,br-data3:compute0.mydomain,br-data4:compute0.mydomain
Related-Bug: #1926693
Change-Id: I692219200535df3af1265248e88c96947e4d8f9d
The admin_* parameters are implementing the same functionality as
keystoneauth parameters alghouth these don't provide all parameters for
Keystone v3 identity but are still based on Keystone v2 identity.
This change deprecates these parameters so that we can remove
such redundant and outdated definitions in a future release.
Closes-Bug: #1927494
Change-Id: I6294098008fbebb2e64922b3aaa085c1361d48a2
When floating IP or port with DNS records are created and the recordset
quota value of the external dns service (e.g. designate) exceeds limit,
the recordset creation fails. Report the exact reason of failure i.e.
ExternalDNSOverQuota instead of HttpException.
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/786174
Closes-Bug: #1923700
Change-Id: Ie1dd5c26ec0eb1875d2a6a176838598117678f4a
This change cleans up the configuration options for Xen API support,
which was deprecated during the Wallaby cycle[1] and have been
ineffective.
[1] a6dbf97242caa3be646e8eb6b1502b5e59e123fd
Change-Id: I89f304f767b2ec645ac7bb216890b6ac470fd875
Until the migration to the new native "nftables" API is completed,
Neutron Linux Bridge mechanism driver can work with:
- The legacy binaries ("iptables", "ip6tables", "arptables" and
" ebtables").
- The "nftables" legacy API tools. "ipset" tool is not compatible
with "nftables" and must be disabled.
Closes-Bug: #1915341
Related-Bug: #1508155
Related-Bug: #1922892
Change-Id: I10ef4e9124ba8f243680acde506eebc586c2f9a7
In TripleO we are moving to a model where heat is not
used to manage neutron resources. This work relies on
using tags, and we are hitting the 60 characther limit.
This change bumps the tag elements to 255 characters.
Closes-Bug: #1921713
Change-Id: Ie69526acb94b62fd5d8db1dbddc1f24072df7a5e
In the fix for #1853840 I made a mistake and since then we created
the physical NIC resource providers as a child of the hypervisor
resource provider instead of the agent resource provider. Here:
https://review.opendev.org/c/openstack/neutron/+/696600/3/neutron/agent/common/placement_report.py#159
This *did not* break the minimum bandwidth aware scheduling.
But still there are multiple problems:
1) If you created your physical NIC RPs before the fix for #1853840
but upgraded to after the fix for #1853840, then resource syncs
will throw an error in neutron-server at each physical NIC RP
update. That pollutes the logs and wastes some resources since
the prohibited update will be forever retried.
2) If you created your physical NIC RPs after the fix for #1853840
then your physical NIC RPs have the wrong parent. Which again
does not break minimum bandwidth aware scheduling. But it may pose
problems for later features wanting to build on the originally
planned RP tree structure.
3) Cleanup of decommissioned RPs is a bit different than expected.
This cleanup was always left to the admin, so it only affects a
manual process.
The proper RP structure was and should be the following:
The hypervisor RP(s) must be the root(s).
As a child of each hypervisor RP, there should be an agent RP.
The physical NIC RPs should be the children of the agent RPs.
Unfortunately at the moment the Placement API generically prohibits
update of the parent resource provider id in a PUT request:
https://docs.openstack.org/api-ref/placement/?expanded=update-resource-provider-detail#update-resource-provider
Therefore without a later Placement change we cannot fix the RPs
already created with the wrong parent. However we can fix the RPs
to be created later. We do that here. We also fix a bug in the unit
tests that allowed the wrong parent to pass unnoticed. Plus we
add an extra log message to direct the user seeing the pollution
in the logs to the proper bug report.
There may be a follow up patch later, because not all RP re-parenting
operations are problematic, therefore we are thinking of relaxing
this blanket prohibition in Placement. When Placement allows updates
to the parent id we can fix RPs already created with the wrong parent
too.
Change-Id: I7caa8827d22103600ca685a58294640fc831dbd9
Closes-Bug: #1921150
Co-Authored-By: "Balazs Gibizer" <balazs.gibizer@est.tech>
Related-Bug: #1853840
Add support in SR-IOV mechanism driver for VNIC type
"accelerator-direct".
This VNIC type refers to any device that supports hardware
acceleration of any kind and is provided by Cyborg [1].
NOTE: "accelerator-direct-physical" is not supported yet.
[1]https://wiki.openstack.org/wiki/Cyborg
Change-Id: I529e6a2a445a140dca7686976efeefcd13d333f0
Closes-Bug: #1909100
This patch enables the "mcast_flood_reports" and "mcast_flood" (on provnet
ports only) options in the Logical Switch Ports in the OVN driver. Without
these options, the ovn-controller will consume the IGMP queries and won't
send it to the LSP ports, meaning that external IGMP queries will never
arrive to the VMs.
In talks to the core OVN team, it was suggested [0] to enable the
"mcast_flood_reports" option by default in the OVN driver (at least until
fixed in core OVN) as a workaround to this problem. And, to avoid having
to update all ports (which can be many) based on the igmp_snooping_enable
configuration option, we are always setting "mcast_flood_reports" to
"true" in the LSPs. This won't cause any harm (also confirmed by core
OVN developers [0]) since it will be ignored if multicast snoop is
disabled.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1933990#c3
Closes-Bug: #1918108
Change-Id: I99a60b9af94b8208b5818b035e189822981bb269
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
This is patchset 2 of 2 for OVN driver handling of security-group-logging.
It includes the core changes and tests for this feature.
This feature requires OVN 20.12 [0] or newer. Functional test will be
skipped for non-supported versions.
Related-Bug: 1468366
Closes-Bug: 1914757
[0]: 880dca99ea
Change-Id: Ic86fa70eb34c9b178267b80de1f8883a3ef03e98
Signed-off-by: Flavio Fernandes <flaviof@redhat.com>
Now is possible to define a gateway IP when creating a subnet using a
subnet pool. The IPAM subnet generator retrieves the available IP
ranges in the subnet pool and generates a list of candidate subnets
with the prefix lenght defined. If the gateway IP can be allocated in
one of those candidate subnets, the IPAM returns a valid IpamSubnet
that will be used to create a Neutron subnet.
Closes-Bug: #1904436
Change-Id: Ib1d1f591c4d0f59ebff3ddcb3be7b10b0b5e67dc
Ports with device_owner like:
* floating_ip,
* DHCP,
* some types of router ports, like: HA interface interface,
* distributed ports,
don't need to be configured in the dnsmasq file.
So there is no need to reload dnsmasq every time when such port is
added/updated to the network.
This patch adds skip in such case which should improve load on the
Neutron DHCP agent.
Closes-Bug: #1913269
Change-Id: I63221507713b941c261cdf88781133149da8ab8d
This change adds VNIC type vDPA ("vdpa") to the list of
supported VNIC types for the OVS and OVN mech drivers.
Depends-On: https://review.opendev.org/#/c/760043/
Change-Id: If22aedc147f7e2256f8f8ad3bebb80b6bb2f6d3d
Support security group rules with remote_address_group_id in openvswitch
firewall. This change reuses most of the firewall functions handling remote
security groups to also process remote address groups. The conjunctive flows
for a rule with remote_adress_group_id are similar to others with
remote_group_id but have different conj_ids.
Change-Id: I8c69e62ba56b0d3204e9c12df3133126071b92f7
Implements: blueprint address-groups-in-sg-rules
Replace rootwrap execution with privsep context execution.
This series of patches will progressively replace any
rootwrap call.
This patch replaces some "IpNetnsCommand" command execution
methods.
Change-Id: Ic5fdf221a2a2cd0951539b0e040d2a941feee287
Story: #2007686
Task: #41558
Added a new port extension: device profile (``port_device_profile``).
This extension adds the "device_profile" parameter to the "port" API
and specifies the device profile per port. This parameter is a
string.
This parameter is passed to Nova and Nova retrieves the requested
device profile from Cyborg. Reference:
https://docs.openstack.org/api-ref/accelerator/v2/index.html#
device-profiles
For backwards compatibility, this parameter will be "None" by
default.
Closes-Bug: #1906602
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/767586
Change-Id: I1202a8388e64ae4270ef4ca118993504ae7c1731