fee98b7147
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
32 lines
1.4 KiB
ReStructuredText
32 lines
1.4 KiB
ReStructuredText
=================================
|
|
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.
|
|
|
|
Also the following API operations are not supported in the 19.0.0 (Stein)
|
|
version of nova:
|
|
|
|
* Moving (resizing, migrating, live-migrating, evacuating, unshelving after
|
|
shelve offload) servers with ports having resource request is not yet
|
|
supported.
|
|
|
|
As of 20.0.0 (Train), nova supports cold migrating 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 using the latest RPC version.
|