openstack/nova
Code Issues Proposed changes
84a84f7f2f
nova/api-guide/source/port_with_resource_request.rst

54 lines
2.3 KiB
ReStructuredText
Raw Normal View History

Documentation for bandwidth support blueprint: bandwidth-resource-provider Depends-On: https://review.openstack.org/#/c/640390 Depends-On: https://review.openstack.org/#/c/621494 Change-Id: I166787e092e16857d20f89fba965be2a5509fb4b
2019-03-08 11:15:16 +01:00
=================================
Using ports with resource request
=================================
Starting from microversion 2.72 nova supports creating servers with neutron
ports having resource request visible as a admin-only port attribute
``resource_request``. For example a neutron port has resource request if it has
a QoS minimum bandwidth rule attached. Deleting such servers or detaching such
ports works since Stein version of nova without requiring any specific
microversion.
However the following API operations are still not supported in nova:
* Creating servers with neutron networks having QoS minimum bandwidth rule is
not supported. The user needs to pre-create the port in that neutron network
and create the server with the pre-created port.
* Attaching Neutron ports and networks having QoS minimum bandwidth rule is not
supported.
Allow migrating server with port resource request 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
2019-07-18 15:44:34 +02:00
Also the following API operations are not supported in the 19.0.0 (Stein)
version of nova:
Documentation for bandwidth support blueprint: bandwidth-resource-provider Depends-On: https://review.openstack.org/#/c/640390 Depends-On: https://review.openstack.org/#/c/621494 Change-Id: I166787e092e16857d20f89fba965be2a5509fb4b
2019-03-08 11:15:16 +01:00
* Moving (resizing, migrating, live-migrating, evacuating, unshelving after
shelve offload) servers with ports having resource request is not yet
supported.
Allow resizing server with port resource request 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
2019-08-27 15:05:55 +02:00
As of 20.0.0 (Train), nova supports cold migrating and resizing servers with
neutron ports having resource requests if both the source and destination
compute services are upgraded to 20.0.0 (Train) and the
``[upgrade_levels]/compute`` configuration does not prevent the computes from
Disable qos resize tempest test for nova-multi-cell job 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
2020-12-10 14:33:08 +01:00
using the latest RPC version. However cross cell resize and cross cell migrate
Fallback to same-cell resize with qos ports 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
2020-12-14 10:37:05 +01:00
operations are still not supported with such ports and Nova will fall back to
same-cell resize if the server has such ports.
Allow resizing server with port resource request 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
2019-08-27 15:05:55 +02:00
Enable unshelve with qos ports 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
2020-03-18 10:56:32 +01:00
As of 21.0.0 (Ussuri), nova supports evacuating, live migrating and unshelving
servers with neutron ports having resource requests.
Enable evacuation with qos ports 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
2019-10-15 13:49:53 +02:00
Support interface attach with QoS ports 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
2020-10-09 15:56:56 +02:00
As of 23.0.0 (Wallaby), nova supports attaching neutron ports having QoS
minimum bandwidth rules.
Reject server create with extended resource req 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
2021-05-28 16:49:50 +02:00
Extended resource request
~~~~~~~~~~~~~~~~~~~~~~~~~
[doc] port-resource-request-groups not landed in Xena 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
2021-09-06 13:03:22 +02:00
It is expected that neutron 20.0.0 (Yoga) will implement an extended resource
request format via the the ``port-resource-request-groups`` neutron API
extension. As of nova 24.0.0 (Xena), nova already supports this extension if
every nova-compute service is upgraded to Xena version and the
``[upgrade_levels]/compute`` configuration does not prevent the computes from
using the latest RPC version.
Support boot with extended resource request 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
2021-07-15 10:51:33 +02:00
Allow resizing server with port resource request 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
2019-08-27 15:05:55 +02:00
See :nova-doc:`the admin guide <admin/port_with_resource_request.html>` for
administrative details.
Copy Permalink