openstack/openstack-manuals
Code Issues Proposed changes

Fix docs covering mismatch between flavor/image

Browse Source 
If there is a mismatch between flavor extra-specs and image properties
the result varies depending on the specific options being configured.

This fixes up the docs to align with the nova code.

Change-Id: Ie42bf8e9a98a055411fc2e2b28ce00cb13af4725
Partial-Bug: 1687077
This commit is contained in:
Chris Friesen 2017-04-28 11:38:45 -06:00 committed by Alexandra Settle
parent 121b7a06f3
commit 97a025801f
2 changed files with 27 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
doc/admin-guide/source/compute-cpu-topologies.rst
View File

@ -242,15 +242,22 @@ image to use pinned vCPUs and avoid thread siblings, run:
--property hw_cpu_policy=dedicated \
--property hw_cpu_thread_policy=isolate
Image metadata takes precedence over flavor extra specs. Thus, configuring
competing policies causes an exception. By setting a ``shared`` policy
through image metadata, administrators can prevent users configuring CPU
policies in flavors and impacting resource utilization. To configure this
policy, run:
If the flavor specifies a CPU policy of ``dedicated`` then that policy will be
used. If the flavor explicitly specifies a CPU policy of ``shared`` and the
image specifies no policy or a policy of ``shared`` then the ``shared`` policy
will be used, but if the image specifies a policy of ``dedicated`` an exception
will be raised. By setting a ``shared`` policy through flavor extra-specs,
administrators can prevent users configuring CPU policies in images and
impacting resource utilization. To configure this policy, run:
.. code-block:: console
$ openstack image set [IMAGE_ID] --property hw_cpu_policy=shared
$ openstack flavor set m1.large --property hw:cpu_policy=shared
If the flavor does not specify a CPU thread policy then the CPU thread policy
specified by the image (if any) will be used. If both the flavor and image
specify a CPU thread policy then they must specify the same policy, otherwise
an exception will be raised.
.. note::
@ -344,10 +351,11 @@ maximum of one thread, run:
--property hw_cpu_max_sockets=2 \
--property hw_cpu_max_threads=1
Image metadata takes precedence over flavor extra specs. Configuring competing
constraints causes an exception. By setting a ``max`` value for sockets, cores,
or threads, administrators can prevent users configuring topologies that might,
for example, incur an additional licensing fees.
The value specified in the flavor is treated as the abolute limit. The image
limits are not permitted to exceed the flavor limits, they can only be equal
to or lower than what the flavor defines. By setting a ``max`` value for
sockets, cores, or threads, administrators can prevent users configuring
topologies that might, for example, incur an additional licensing fees.
For more information about image metadata, refer to the `Image metadata`_
guide.

16
doc/admin-guide/source/compute-huge-pages.rst
View File

@ -79,7 +79,7 @@ transparent huge pages (``AnonHugePages``) allocated. Huge pages can be
allocated at boot time or run time. Huge pages require a contiguous area of
memory - memory that gets increasingly fragmented the long a host is running.
Identifying contiguous areas of memory is a issue for all huge page sizes, but
it's particularly problematic for larger huge page sizes such as 1 GB huge
it is particularly problematic for larger huge page sizes such as 1 GB huge
pages. Allocating huge pages at boot time will ensure the correct number of huge
pages is always available, while allocating them at run time can fail if memory
has become too fragmented.
@ -214,15 +214,17 @@ of flavor. To configure an image to use 1 GB huge pages, run:
$ openstack image set [IMAGE_ID] --property hw_mem_page_size=1GB
Image metadata takes precedence over flavor extra specs. Thus, configuring
competing page sizes causes an exception. By setting a ``small`` page size
through image metadata, administrators can prevent users requesting huge pages
in flavors and impacting resource utilization. To configure this page size,
run:
If the flavor specifies a numerical page size or a page size of "small" the
image is not allowed to specify a page size and if it does an exception will
be raised. If the flavor specifies a page size of ``any`` or ``large`` then
any page size specified in the image will be used. By setting a ``small``
page size in the flavor, administrators can prevent users requesting huge
pages in flavors and impacting resource utilization. To configure this page
size, run:
.. code-block:: console
$ openstack image set [IMAGE_ID] --property hw_mem_page_size=small
$ openstack flavor set m1.large --property hw:mem_page_size=small
.. note::