From 97a025801f8a75f79ae6ff4f2ddb165fb5a3ffcb Mon Sep 17 00:00:00 2001 From: Chris Friesen Date: Fri, 28 Apr 2017 11:38:45 -0600 Subject: [PATCH] Fix docs covering mismatch between flavor/image 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 --- .../source/compute-cpu-topologies.rst | 28 ++++++++++++------- doc/admin-guide/source/compute-huge-pages.rst | 16 ++++++----- 2 files changed, 27 insertions(+), 17 deletions(-) diff --git a/doc/admin-guide/source/compute-cpu-topologies.rst b/doc/admin-guide/source/compute-cpu-topologies.rst index f38c49bbfc..a55d587ef2 100644 --- a/doc/admin-guide/source/compute-cpu-topologies.rst +++ b/doc/admin-guide/source/compute-cpu-topologies.rst @@ -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. diff --git a/doc/admin-guide/source/compute-huge-pages.rst b/doc/admin-guide/source/compute-huge-pages.rst index 03074cada5..55f9fbfc13 100644 --- a/doc/admin-guide/source/compute-huge-pages.rst +++ b/doc/admin-guide/source/compute-huge-pages.rst @@ -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::