openstack
/
placement
Code Issues Proposed changes

Follow up for placement usage document 

This patche addresses the following review comments from earlier
in this series:

https://review.openstack.org/#/c/604243/4/doc/source/usage/index.rst@28
https://review.openstack.org/#/c/604243/4/doc/source/usage/provider-tree.rst@190
https://review.openstack.org/#/c/604243/4/doc/source/usage/provider-tree.rst@264

Change-Id: I15097a850cf6f6f33d42234f6e3a72d103d6bc42
This commit is contained in:
Tetsuro Nakamura 2018-09-27 20:26:55 +09:00
parent 111aa59869
commit 1e617ea3a1
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/usage/index.rst
View File

@ -25,7 +25,7 @@ via the placement REST API.
The nova resource tracker is responsible for creating the resource provider The nova resource tracker is responsible for creating the resource provider
record corresponding to the compute host on which the resource tracker runs. record corresponding to the compute host on which the resource tracker runs.
If other projects -- for example, Neutron or Cyborg -- wish to manage resources If other projects -- for example, Neutron or Cyborg -- wish to manage resources
on a compute host, the should create resource providers as children of the on a compute host, they should create resource providers as children of the
compute host provider and register their own managed resources as inventory on compute host provider and register their own managed resources as inventory on
those child providers. For more information, see the those child providers. For more information, see the
:doc:`Modeling with Provider Trees <provider-tree>`. :doc:`Modeling with Provider Trees <provider-tree>`.

10
doc/source/usage/provider-tree.rst
View File

@ -187,8 +187,8 @@ would return two candidates.
2. ``NUMA1_2`` (``VCPU``) + ``CN1`` (``MEMORY_MB``, ``DISK_GB``) 2. ``NUMA1_2`` (``VCPU``) + ``CN1`` (``MEMORY_MB``, ``DISK_GB``)
This is because ``SS1`` is not in aggregate A, and because aggregate B on This is because ``SS1`` is not in aggregate A, and because aggregate B on
``NUMA2_1`` doesn't span the whole tree since it isn't a root resource ``NUMA2_1`` doesn't span the whole tree since the ``NUMA2_1`` resource
provider. provider isn't a root resource provider.
Filtering by Traits Filtering by Traits
=================== ===================
@ -261,9 +261,9 @@ Granular Resource Requests
========================== ==========================
If you want to get the same kind of resources from multiple resource providers If you want to get the same kind of resources from multiple resource providers
at once, or if you don't want to spread the trait/aggregate constraints across at once, or if you require a provider of a particular requested resource
multiple resource providers, you can use the `Granular Resource Request`_ class to have a specific trait or aggregate membership, you can use the
feature. `Granular Resource Request`_ feature.
This feature is enabled by numbering the ``resources``, ``member_of`` and This feature is enabled by numbering the ``resources``, ``member_of`` and
``required`` query parameters respectively. ``required`` query parameters respectively.