The aim of the RFE is to improve the previous implemented RFE
Strict minimum bandwidth support [1].
[1]https://bugs.launchpad.net/neutron/+bug/1578989
Related-Bug: #1991965
Change-Id: I21a1d9bee1d195f704a518ea3dbd3f2b1e35a357
Neutron adds distributed attributes to each Floating IP.
Users can set this attribute according to their actual
environment and use requirements.
see more [1]
[1] https://bugs.launchpad.net/neutron/+bug/1978039
Related-Bug: #1978039
Change-Id: Ibdaa0ae502b5fd413cb08e68356e0c18463c4974
The proposed spec is to extend the current feature routed provider
networks to allow provisioning more than one segment per physical
network.
The support is for OVS only.
Related-Bug: #1764738
Related-Bug: #1956435
Change-Id: I00e32b5b4fc6e4127ac3a56c7d34a1b828e6cb02
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
As we run into a nasty setuptools issue/feature which broke even
tox -edocs, add py_modules=[] to setup.py's setup call, see [1].
[1]: https://review.opendev.org/q/topic:setuptools-issue-3197
Change-Id: I24adbcb9076f02c2eeefef98c21a4ccf247b0c5b
During the review of the Nova and Neutron implementations the
wording used changed from "board serial number" to "card serial
number".
Partial-Bug: #1932154
Change-Id: Ib342351cad3ff1cd46016c1fcfe05e05bf92bf2b
https://blueprints.launchpad.net/neutron/+spec/off-path-smartnic-dpu-port-binding-with-ovn
Off-path SmartNIC DPUs introduce an architecture change where network
agents responsible for NIC switch configuration and representor
interface plugging run on a separate SoC with its own CPU, memory and
that runs a separate OS kernel. The side-effect of that is that
hypervisor hostnames no longer match SmartNIC DPU hostnames which are
seen by ovs-vswitchd and OVN agents while the existing port binding
code relies on that. The goal of this specification is to introduce
changes necessary to extend the existing hardware offload code to cope
with the hostname mismatch and related design challenges while reusing
the rest of the code. To do that, PCI(e) add-in card tracking is
introduced for boards with unique serial numbers so that it can be used
to determine the correct hostname of a SmartNIC DPU which is responsible
for a particular VF. Additionally, more information is suggested to be
passed in the "binding:profile" during a port update to facilitate
representor port plugging.
WIP code: https://review.opendev.org/c/openstack/neutron/+/808961
Nova spec: https://review.opendev.org/c/openstack/nova-specs/+/787458
Nova BP: https://blueprints.launchpad.net/nova/+spec/integration-with-off-path-network-backends
Needed-By: I07ef52769da72cde8867f996111b7df4a80e4d79
Change-Id: Ic8db22d1b6570f68bd6400ecc653dc893a4b6184
Closes-Bug: #1932154
The implementation of the qos-minimum-guaranteed-packet-rate spec did
not land in Xena so this patch moves it to the Yoga folder. Also it
extends the space based on findings during the implementation work.
Related-Bug: 1922237
Change-Id: I5ed384be490ad3962e274ad94ce28060bd6fe96b
This spec proposes to add an intermediate bridge between the VM patch
port and the integration bridge. That will allow the backend (OVN)
to properly configure the needed OpenFlow rules before the VM
is unpaused in the destination host. That will reduce the
networking disruption during the live migration process.
Change-Id: I558523a8922567efb0739173c7c2fda72504a8fe
Related-Bug: #1933517
Adding the spec to support Node-Local Virtual IP for the RFE
https://bugs.launchpad.net/neutron/+bug/1930200
Partial-Bug: #1930200
Co-Authored-By: obondarev <oleg.bondarev@huawei.com>
Change-Id: If9f137a839b37f8262f4842b34401a13967ed43e
There was a comment from Rodolfo to add the resource_provider_ prefix
for the new packet processing config options but I forgot to add it to
the packet_processing_inventory_defaults config name. Fixed it now so
all the three new config option names have the same prefix.
Related-Bug: 1922237
Change-Id: I3018715e1265aff70002711a06b2bf5ee9ba53a5
Similarly to how bandwidth can be a limiting factor of a network
interface, packet processing capacity tend to be a limiting factor
of the soft switching solutions like OVS. In the same time certain
applications are dependent on not just guaranteed bandwidth but also
on guaranteed packet rate to function properly. OpenStack already
supports bandwidth guarantees via the minimum bandwidth QoS policy
rules. This specification is aiming for adding support for a similar
minimum packet rate QoS policy rule.
Related-Bug: 1922237
Change-Id: Id17ee01dc288517a05f746a479500a6218ad55f4