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.
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.
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
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.
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.
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
The following logic is added to the ComputeManager attach_interface
* gather the resource request of the port from neutron
* query allocation candidates restricted to the current compute node
* 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.
This change extends the conductor manager to append the cyborg
resource request to the request spec when performing an unshelve.
On shelve offload an instance will be deleted the instance's ARQs
binding info to free up the bound ARQs in Cyborg service.
And this change passes the ARQs to spawn during unshelve an instance.
This change extends the ``shelve_instance``, ``shelve_offload_instance``
and ``unshelve_instance`` rpcapi function to carry the arq_uuids.
Co-Authored-By: Wenping Song <firstname.lastname@example.org>
Implements: blueprint cyborg-shelve-and-unshelve
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
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.
This change extends the conductor manager
to append the cyborg resource request to the
request spec when performing an evacuate.
This change passes the ARQs to spawn during rebuild
and evacuate. On evacuate the existing ARQs will be deleted
and new ARQs will be created and bound, during rebuild the
existing ARQs are reused.
This change extends the rebuild_instance compute rpcapi
function to carry the arq_uuids. This eliminates the
need to lookup the uuids associated with the arqs assinged
to the instance by quering cyborg.
Co-Authored-By: Wenping Song <email@example.com>
Co-Authored-By: Brin Zhang <firstname.lastname@example.org>
Implements: blueprint cyborg-rebuild-and-evacuate
Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.
Switch to openstackdocstheme 2.1.2 and reno 3.1.0 versions. Using
these versions will allow parallelizing building of documents.
Update Sphinx version as well.
openstackdocstheme renames some variables, so follow the renames. A
couple of variables are also not needed anymore, remove them.
Set openstackdocs_auto_version to not version the documents.
Set openstackdocs_auto_name to use project as name.
In 21.0.0 Ussuri we were completed the nova-cyborg interaction feature,
but there are some issue when multiple create instances.
Creating servers with accelerators provisioned with the Cyborg service,
if a flavor asks for resources that are provided by nested Resource
Provider inventories (eg. VGPU) and the user wants multi-create (ie. say
--max 2) then the scheduler could be returning a NoValidHosts exception
even if each nested Resource Provider can support at least one specific
instance, if the total wanted capacity is not supported by only one
For example,creating servers with accelerators provisioned with the
Cyborg service, if two children RP have 4 VGPU inventories each:
- you can ask for a flavor with 2 VGPU with --max 2
- but you can't ask for a flavor with 4 VGPU and --max 2
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.
Microversion bump to allow non-admin user to use more filters key
when listing instances.
In order to stay coherent, all existing instance filters who are
related to a field readable by default to non admin users when showing
instance details, should be allowed by default without policy
Implements: blueprint non-admin-filter-instance-by-az
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.
This legacy service is no longer used and was deprecated during the
Stein cycle . It's time to say adios and remove them in their
entirety. This is pretty straightforward, with the sole exception of
schema for the 'remote-consoles' API, which has to continue supporting
requests for type 'xvpvnc' even if we can't fulfil those requests now.
Part of blueprint remove-xvpvncproxy
Signed-off-by: Stephen Finucane <email@example.com>
The API guide on faults has a section on server actions
but just links to the API reference. There is also the
"Asynchronous faults" section at the bottom which refers
to the server actions API but does not go into details.
This fleshes that section on server actions out a bit more
and includes a walkthrough on the command line of a failed
resize due to NoValidHost. I chose this example since the
server status does not change to ERROR so there is no fault
to see in the server details when the resize action fails.
Get excited, people. It's finally dying, for real. There is a lot more
doc work needed here, but this is a start. No need for a release note
modification since we've already said that nova-network has been
removed, so there's no point in saying that the service itself has been
removed since that's implicit.
Signed-off-by: Stephen Finucane <firstname.lastname@example.org>
The todos here are just kind of embarrassing so rather than try
to flesh these out we should just remove them.
The alternative would be writing something at a very high level
like 'the compute service works with the image service to get
the guest operating system image and create snapshots', 'the
compute service works with the block storage service to use
persistent volumes as root volumes with an operating
system image or data volumes', 'the compute service works with
the networking service to provide network access to the server
and firewall rules using security groups' and then link to the
glance, cinder and neutron docs, but I'm not sure it's worth it.
This is pretty basic. As for the todo about using named
personas I've just removed that since I don't think at
this point anyone is going to work on assigning names like
Bob and Sally to roles in the guide and consistently use them.
This just gives a high level about how the compute and network
service interact along with the most important networking
resources (ports, networks, security groups and floating IPs).
This adds high level details and links to more detailed docs
in both nova and glance.
This also un-hides the document so it shows up in the table of
contents on the main page. Previously it was being linked from
the general info page and some typos in there are fixed as well.
When these docs were initially imported  the "Considerations"
section was after "Server personality" but  refactored the
latter and forgot about the former. This fixes that so
"Considerations" is now just nested into the "Server personality"
Two things here:
1. The API guide was missing the hyper-v driver which supports
the suspend operation. Rather than hard-code a list of supported
drivers in the doc, this change just links to the entry in the
feature support matrix.
2. The supported hypervisors mention in the API reference is removed
because the end user using the API should not need to know or care
what backend hypervisor on which their server is running. They can
either suspend or not, but we don't need to mention the supporting
drivers for that in the API reference.
Previous patch  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.
Add the 'security_groups' parameter as available infomation
in the "List Servers Detailed" API (GET /servers/detail)
when there is a down cell.
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  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_