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_policy=dedicated \
--property hw_cpu_thread_policy=isolate --property hw_cpu_thread_policy=isolate
Image metadata takes precedence over flavor extra specs. Thus, configuring If the flavor specifies a CPU policy of ``dedicated`` then that policy will be
competing policies causes an exception. By setting a ``shared`` policy used. If the flavor explicitly specifies a CPU policy of ``shared`` and the
through image metadata, administrators can prevent users configuring CPU image specifies no policy or a policy of ``shared`` then the ``shared`` policy
policies in flavors and impacting resource utilization. To configure this will be used, but if the image specifies a policy of ``dedicated`` an exception
policy, run: 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 .. 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:: .. note::
@ -344,10 +351,11 @@ maximum of one thread, run:
--property hw_cpu_max_sockets=2 \ --property hw_cpu_max_sockets=2 \
--property hw_cpu_max_threads=1 --property hw_cpu_max_threads=1
Image metadata takes precedence over flavor extra specs. Configuring competing The value specified in the flavor is treated as the abolute limit. The image
constraints causes an exception. By setting a ``max`` value for sockets, cores, limits are not permitted to exceed the flavor limits, they can only be equal
or threads, administrators can prevent users configuring topologies that might, to or lower than what the flavor defines. By setting a ``max`` value for
for example, incur an additional licensing fees. 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`_ For more information about image metadata, refer to the `Image metadata`_
guide. 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 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. 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 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. 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 pages is always available, while allocating them at run time can fail if memory
has become too fragmented. 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 $ openstack image set [IMAGE_ID] --property hw_mem_page_size=1GB
Image metadata takes precedence over flavor extra specs. Thus, configuring If the flavor specifies a numerical page size or a page size of "small" the
competing page sizes causes an exception. By setting a ``small`` page size image is not allowed to specify a page size and if it does an exception will
through image metadata, administrators can prevent users requesting huge pages be raised. If the flavor specifies a page size of ``any`` or ``large`` then
in flavors and impacting resource utilization. To configure this page size, any page size specified in the image will be used. By setting a ``small``
run: 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 .. 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:: .. note::