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
nested RP.
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
Related-Bug: #1874664
Change-Id: I64647a6ba79c47c891134cedb49f03d3c61e8824
This commit adds the documents to explain the new defaults,
migration plan and releases notes for policies changes in
BP policy-defaults-refresh
Partial implement blueprint policy-defaults-refresh
Change-Id: I00e678858a8e46786f3b69fbba3f5353932de49b
Now that allocations are passed to the methods, we can ask whether we
need to use mediated devices for the instance.
Adding a large functional test for verifying it works.
Change-Id: I018762335b19c98045ad42147080203092b51c27
Closes-Bug: #1778563
The term role has became case sensitive since sphinx 3.0.1.
It causes the following warnings and makes a check job fail.
WARNING: term not in glossary: availability zone
This patch fixes the issue.
Change-Id: I1f993b503ef769da0950afa206d6ac4a54f903b4
Closes-Bug: #1872260
It's now possible to have a different vGPU type for each pGPU. By modifying
the config, you can say which PCI device (ie. a pGPU) should use a specific
vGPU type.
For upgrades, the behaviour from Train won't be changed since we only use
the first type if we don't have the dynamic options (so operators don't
need to change nova.conf before upgrading).
Implements: blueprint vgpu-multiple-types
Change-Id: I46f0a76811142888db2bbc66cc3fde04ff890c01
Building on Ic2ad1468d31b7707b7f8f2b845a9cf47d9d076d5, when requested
this microversion will allow boot from volume requests to proceed when
the COMPUTE_RESCUE_BFV trait is also reported by the compute the
instance currently resides on.
Implements: blueprint virt-bfv-instance-rescue
Change-Id: I3242fec1547693078cf36c3637116f8c41f1d0bc
Now that we have a registry of all extra specs known by stock nova, we
can start documenting these. We choose the configuration guide to do
this since configuration of flavor extra specs is traditionally an
admin-only operation.
Part of blueprint flavor-extra-spec-validators
Change-Id: I5ad6576e0d31a29822d1c7b47751ea81828630cf
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Enable support for API-based extra spec validation. Since most of the
hard work has been done in previous patches, all that's necessary here
is to wire up the microversion handling and turn things on.
Part of blueprint flavor-extra-spec-validators
Change-Id: If67f0d924ea372746a6dc440ea7bdc655e4f0bea
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Add the validation framework necessary to verify extra specs along with
the definitions for every extra spec we currently recognize in-tree.
None of this is currently used since we don't have the API microversions
wired up, but that will come in a future patch.
Note that we must add the H238 hacking check to the ignore list here,
since this includes our first use of Python 3-type classes without the
explicit 'object' subclass. This can be removed when that check is
removed from hacking.
Part of blueprint flavor-extra-spec-validators
Change-Id: Ib64a1348cce1dca995746214616c4f33d9d664bd
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
1. Claim allocations from placement first, then claim specific
resources in Resource Tracker on destination to populate
migration_context.new_resources
3. cleanup specific resources when live migration succeeds/fails
Because we store specific resources in migration_context during
live migration, to ensure cleanup correctly we can't drop
migration_context before cleanup is complete:
a) when post live migration, we move source host cleanup before
destination cleanup(post_live_migration_at_destination will
apply migration_context and drop it)
b) when rollback live migration, we drop migration_context after
rollback operations are complete
For different specific resource, we might need driver specific support,
such as vpmem. This change just ensures that new claimed specific
resources are populated to migration_context and migration_context is not
droped before cleanup is complete.
Change-Id: I44ad826f0edb39d770bb3201c675dff78154cbf3
Implements: blueprint support-live-migration-with-virtual-persistent-memory
Allow PUT /servers/{server_id}/os-volume_attachments/{volume_id}``
to support specifying ``delete_on_termination`` field in the request
body. This allows updating the attached volume's flag that controls
whether or not it is automatically deleted when the instance is deleted.
When we request 'volumeId' and 'delete_on_termination' in the requst
body to swap volume, since the new microversion it will be support
updating the swapping volume's delete flag.
Co-Authored-By: Dan Smith <dansmith@redhat.com>
Blueprint: destroy-instance-with-datavolume
Change-Id: I6ccac4e17f56b40e67c79d40f32558ef414685ea
We had recent bug report about a possible regression related to
affinity policy enforcement with parallel server create requests.
It turned out not to be a regression but because of the complexity
around affinity enforcement, it might help to add a section to the
compute troubleshooting doc about it which we could refer to in the
future.
Related-Bug: #1863190
Change-Id: I508c48183a7205d46e13154d4e92d31dfa7f7d78
Since I537ed74503d208957f0a97af3ab754a6750dac20 had some clean-up comments,
we can just provide a follow-up change.
Change-Id: Ie8b5147322e13ad7df966b5c3c41ef0418e4f64c
Related-Bug: #1793569
This adds a new microversion to expose the instance action
event details in the
GET /servers/{server_id}/os-instance-actions/{request_id} API.
With the new microversion the "details" key is always returned
with each event dict but the value may be null because of old
records or events that did not fail.
The details are not constrained by policy like the traceback
field since the details are like a fault message on the server
resource when the server is in ERROR status and the fault
message is likewise not constraint by policy unlike the fault
details which is a traceback like the event traceback field.
This commit add a SYSTEM_READER ('rule: system_reader_api') role
to the Show Server Action Details API. With this default policy,
events fault details can be displayed. And also add some nova and
non-nova exception functional tests for os-instance-actions API.
Co-Authored-By: Brin Zhang <zhangbailin@inspur.com>
Implements blueprint action-event-fault-details
Change-Id: I6fe4dd265b0030ce12f92771b255a3d795f03d01
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
modification.
Implements: blueprint non-admin-filter-instance-by-az
Change-Id: Ia66d3a1ceb74ed521cf44922929b2a502f3ee935
We have a custom of naming the directory after the API. Reinforce that
here.
Change-Id: I5bf68aacc1d987400a91467835c4b55f03c18beb
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The API URL is '/os-keypairs', not '/keypairs'. Attempting to use these
pagination links as-is will result in a HTTP 404 (Not Found).
Change-Id: Ic04568caecc138e6016418f6878d031c4a0d3fb4
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Closes-bug: #1866373
This change documents certain hyper-v driver features that are not
included in the driver support matrix.
Change-Id: I29f6d816138bd31ad6bc8d327636b202d718bdff
APIImpact: Adds 2.82 microversion for /os-server-external-events API.
DocImpact: Adds new version to doc/api_samples/versions/.
Change-Id: I7a626544d8221dc0eeb5672986ca897ce4718be8
Blueprint: nova-cyborg-interaction
Hypervisor view builder's _collection_name,
'hypervisors' is used to build next link that
sdk use as uri to do paginated query. But correct
API should be `GET /v2.1/os-hypervisors?<params>`
rather than `GET /v2.1/hypervisors?<params>`.
This patch fixes this bug.
Change-Id: Idc4f3fe54136a6bd3dbc7dc0efd3f62745991199
Closes-Bug: 1864428
Signed-off-by: Fan Zhang <zh.f@outlook.com>
zhangbailin