Public bug reported:

- [x] This is a doc addition request.

This is coming up from discussion about what to document in the release
notes for the libvirt VGPU reshaper work that happened in Stein:

https://review.openstack.org/#/c/644412/4/releasenotes/notes/stein-
prelude-b5fe92310e1e725e.yaml@57

Specifically about the upgrade impact of VGPU inventory and allocations
moving from the root compute node resource provider to a child resource
provider.

The release notes and docs for VGPUs are not very clear about this
change (the docs don't actually mention anything about it). So this bug
is for tracking that gap.

I think it would be good to at the very least mention that starting in
the Stein release, VGPU inventory and allocations are tracked on a child
resource provider of the root compute node resource provider. And we
could illustrate this using examples from openstack CLIs:

https://docs.openstack.org/osc-placement/latest/index.html

For example, list resource providers where there are two, one for the
root compute node resource provider and one for a VGPU provider. Then
list inventories on each and see there is VCPU/MEMORY_MB/DISK_GB on the
compute node root provider and VGPU inventory on the child provider.
Nothing fancy but something as a way to show, if you set this up
correctly and things are working correctly, this is what you should
expect to see.

-----------------------------------
Release: 18.1.0.dev1645 on 2019-02-27 13:28:37
SHA: 592658aafcb5de8d31b19c8833a8d41ca86a5654
Source: 
https://git.openstack.org/cgit/openstack/nova/tree/doc/source/admin/virtual-gpu.rst
URL: https://docs.openstack.org/nova/latest/admin/virtual-gpu.html

** Affects: nova
     Importance: Medium
         Status: Triaged


** Tags: doc vgpu

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1821015

Title:
  Attaching virtual GPU devices to guests in nova - libvirt reshaping

Status in OpenStack Compute (nova):
  Triaged

Bug description:
  - [x] This is a doc addition request.

  This is coming up from discussion about what to document in the
  release notes for the libvirt VGPU reshaper work that happened in
  Stein:

  https://review.openstack.org/#/c/644412/4/releasenotes/notes/stein-
  prelude-b5fe92310e1e725e.yaml@57

  Specifically about the upgrade impact of VGPU inventory and
  allocations moving from the root compute node resource provider to a
  child resource provider.

  The release notes and docs for VGPUs are not very clear about this
  change (the docs don't actually mention anything about it). So this
  bug is for tracking that gap.

  I think it would be good to at the very least mention that starting in
  the Stein release, VGPU inventory and allocations are tracked on a
  child resource provider of the root compute node resource provider.
  And we could illustrate this using examples from openstack CLIs:

  https://docs.openstack.org/osc-placement/latest/index.html

  For example, list resource providers where there are two, one for the
  root compute node resource provider and one for a VGPU provider. Then
  list inventories on each and see there is VCPU/MEMORY_MB/DISK_GB on
  the compute node root provider and VGPU inventory on the child
  provider. Nothing fancy but something as a way to show, if you set
  this up correctly and things are working correctly, this is what you
  should expect to see.

  -----------------------------------
  Release: 18.1.0.dev1645 on 2019-02-27 13:28:37
  SHA: 592658aafcb5de8d31b19c8833a8d41ca86a5654
  Source: 
https://git.openstack.org/cgit/openstack/nova/tree/doc/source/admin/virtual-gpu.rst
  URL: https://docs.openstack.org/nova/latest/admin/virtual-gpu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1821015/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to     : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Reply via email to