Not as many of these as I thought there would be. Also, yes, the change
to 'nova.conf.compute' is a doc change :)
Change-Id: I27626984ce94544bd81d998c5fdf141875faec92
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
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
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
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
These closely related features are the source of a disproportionate
number of bugs and a large amount of confusion among users. The spread
of information around multiple docs probably doesn't help matters.
Do what we've already done for the metadata service and remote consoles
and clean these docs up. There are a number of important changes:
- All documentation related to host aggregates and availability zones is
placed in one of three documents, '/user/availability-zones',
'/admin/aggregates' and '/admin/availability-zones'. (note that there
is no '/user/aggregates' document since this is not user-facing)
- References to these features are updated to point to the new location
- A glossary is added. Currently this only contains definitions for host
aggregates and availability zones
- nova CLI commands are replaced with their openstack CLI counterparts
- Some gaps in related documentation are closed
Change-Id: If847b0085dbfb4c813d4a8d14d99346f8252bc19
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Now that we reshape inventories and allocations for VGPU resources in Stein,
we think it's good for operators to know how to verify the resources using
osc-placement.
Change-Id: Ic58709aac2dd1f20f1b8440a3cea4f29eed9a965
Closes-Bug: #1821015
FWIW, we already say in the feature classification documentation that the
feature is experimental [1] but we also now have functional tests that help
to verify that the feature is working.
I think we can just remove the note about this then.
[1] https://docs.openstack.org/nova/latest/user/feature-classification.html#operation_virtual_gpu
Change-Id: I705b3aeb1da33ddc41d4306ad91ad7cb70fcf4e4
Add a note to the documentation,the GPU vendor's VGPU
driver software needs to be installed and configured.
Change-Id: I8618a312818f6f26d358b40e723fecf74c0d2eb7
When rescuing an instance having a vGPU, we were not using the vGPU.
There would then be a race condition during the rescue where the vGPU
could be passed to another instance.
Instead, we should just make sure the vGPU would also be in the rescued
instance.
Change-Id: I7150e15694bb149ae67da37b5e43b6ea7507fe82
Closes-bug: #1762688
This ensures we have version-specific references to other projects [1].
Note that this doesn't mean the URLs are actually valid - we need to do
more work (linkcheck?) here, but it's an improvement nonetheless.
[1] https://docs.openstack.org/openstackdocstheme/latest/#external-link-helper
Change-Id: Ifb99e727110c4904a85bc4a13366c2cae300b8df
This commit is to update support matrix and doc for VGPU feature
on XenAPI.
Implements: blueprint add-support-for-vgpu
Change-Id: I0c9797d1f274e37e3b084d94d0b85980260b2861
Now that Queens supports attaching virtual GPUs to an instance, we need to
properly document which hypervisors support that, how to use that feature and
what the existing caveats are.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Change-Id: I871894c3584e92f80f6420dfc009e21b30450f8e
Implements: blueprint add-support-for-vgpu
Stephen Finucane