This patches adjusts the nova documentation about the extended port
resource request support in nova as the neutron API extension did not
land in Xena.
Change-Id: I3b961426745084bdb4a6d04468f5a3c762be4cfa
blueprint: qos-minimum-guaranteed-packet-rate
The interface attach and detach logic is now fully adapted to the new
extended resource request format, and supports more than one request
group in a single port.
blueprint: qos-minimum-guaranteed-packet-rate
Change-Id: I73e6acf5adfffa9203efa3374671ec18f4ea79eb
Nova re-generates the resource request of an instance for each server
move operation (migrate, resize, evacuate, live-migrate, unshelve) to
find (or validate) a target host for the instance move. This patch
extends the this logic to support the extended resource request from
neutron.
As the changes in the neutron interface code is called from nova-compute
service during the port binding the compute service version is bumped.
And a check is added to the compute-api to reject the move operations
with ports having extended resource request if there are old computes
in the cluster.
blueprint: qos-minimum-guaranteed-packet-rate
Change-Id: Ibcf703e254e720b9a6de17527325758676628d48
This adds the final missing pieces to support creating servers with
ports having extended resource request. As the changes in the neutron
interface code is called from nova-compute service during the port
binding the compute service version is bumped. And a check is added to
the compute-api to reject such server create requests if there are old
computes in the cluster.
Note that some of the negative and SRIOV related interface attach
tests are also started to pass as they are not dependent on any of the
interface attach specific implementation. Still interface attach is
broken here as the failing of the positive tests show.
blueprint: qos-minimum-guaranteed-packet-rate
Change-Id: I9060cc9cb9e0d5de641ade78c5fd7e1cc77ade46
To prepare for the unlikely event that Neutron merges and an operator
enables the port-resource-request-groups neutron API extension before
nova adds support for it, this patch rejects server creation if such
extension is enabled in Neutron. Enabling that extension has zero
benefits without nova support hence the harsh but simple rejection.
A subsequent patch will reject server lifecycle operations in a more
sophisticated way and as soon as we support some operations, like
boot, the deployer might rightfully choose to enable the Neutron
extension.
Change-Id: I2c55d9da13a570efbc1c862116cea31aaa6aa02e
blueprint: qos-minimum-guaranteed-packet-rate
The following logic is added to the ComputeManager attach_interface
flow:
* gather the resource request of the port from neutron
* query allocation candidates restricted to the current compute node
from placement
* extend the existing allocation of the instance with one of the
allocation candidates in placement
* update the InstancePCIRequest (if any) to ensure that the PCI claim
only allocates VF from the PF the placement resources are allocated from
* ensure that during port binding neutron gets the RP UUID, the resources
are allocated from, in the allocation key of the binding profile
This patch bumps the compute service version to indicate that QoS
interface attach is supported. Also the check that was so far rejected
such attach is now updated to only reject it if the compute service
version is too old.
The "scheduling" during interface attach for PCI backed ports has the
same limitation as normal scheduling for such ports. It always selects
the first allocation candidate returned by placement even if later in
the process it turns out that such allocation candidate points to a PCI
PF that has no free VFs left.
Blueprint: support-interface-attach-with-qos-ports
Change-Id: Id4684093e8bdf3b61667490443e3d2f6ed65f4b3
The cross-cell resize code does not consider neutron ports with resource
request. To avoid migration failures this patch makes nova to fall back
to same cell resize if the instance has neutron ports with resource
request.
Change-Id: Icaad4b2375b491c8a7e87fb6f4977ae2e13e8190
Closes-Bug: #1907522
It turned out that during the qos resize work we did not implemented
support of cross cell resize with qos ports. Tempest test coverage for
the resize and migrate is landed recently that made the nova-multi-cell
job to fail.
So this patch disables the qos resize and migrate tempest tests for the
nova-multi-cell job to unblock the gate.
Related-Bug: #1907522
[1] I8c573c4a11a76932057d8415d76114a03269b9f3
Change-Id: I95bc22f7d65454cd9e7b54a0e6d9516f2f204978
Previous patches in the blueprint implemented the support for unshelve
with qos ports and added functional test coverage for the
various scenarios. So this patch changes the API check
that rejected such operation to check for the service version and therefore
conditionally enable the feature.
Change-Id: Iaf70ee41f1bfb1a4964da3f59cd3a0b4b5e20d36
blueprint: support-move-ops-with-qos-ports-ussuri
Previous patches in the blueprint implemented the support for live
migraton with qos ports and added functional test coverage for the
various live migration scenarios. So this patch removes the API check
that rejected such operation and document the new feature.
Change-Id: Ib9ef18fff28c463c9ffe3607d93428b689dc89fb
blueprint: support-move-ops-with-qos-ports-ussuri
Previous patch [1] implemented support for evacuation of servers with
neutron ports having resource request. So this patch removes the API
check that rejected such operations and document the new feature.
[1] Id9ed7a82d42be8ffe760f03e6610b9e6f5a4287b
Change-Id: Id5f2f4f22b856c989e2eef8ed56b9829d1bcefb6
blueprint: support-move-ops-with-qos-ports-ussuri
This patch adds functional coverage for such resize. No extra code
changes were needed on top of the migrate patches to make resize work.
Now that the nova code supports the resize this patch removes the
check from the API that rejected the operation.
Note that in the spec [1] we agreed not to introduce new microversion
for this change but treat it as a bugfix. The current change also makes
it possible to accept the resize of these servers with _any_
microversion.
[1] https://specs.openstack.org/openstack/nova-specs/specs/train/approved/support-move-ops-with-qos-ports.html#rest-api-impact
blueprint: support-move-ops-with-qos-ports
Change-Id: Id0ee10e8d323786f4d79c82e3f05b48e76bd0956
Now that the nova code supports such a migration this patch removes the
check from the API that rejected the operation.
Note that in the spec [1] we agreed not to introduce new microversion
for this change but treat it as a bugfix. The current change also makes
it possible to accept the migration of these servers with _any_
microversion.
[1] https://specs.openstack.org/openstack/nova-specs/specs/train/approved/support-move-ops-with-qos-ports.html#rest-api-impact
Change-Id: I4bda569cc7c247e83219276282724c77e760ddcd
blueprint: support-move-ops-with-qos-ports
