From c7d7f18ba2f9c535406c063d94249b31ccd48499 Mon Sep 17 00:00:00 2001 From: Dmitry Tantsur Date: Tue, 8 Aug 2017 14:06:29 +0200 Subject: [PATCH] Update the resource classes documentation based on recent progress The feature works now, so we can remove uncertaincy from the docs. Also adds an upgrade release note to populate the resource_class field before the upgrade. Change-Id: I22234aafdd195dd76c621b93042a67cdb36f3e65 --- doc/source/admin/upgrade-guide.rst | 2 +- doc/source/install/configure-compute.rst | 20 ++++-- doc/source/install/configure-nova-flavors.rst | 69 ++++++++++++------- .../resource-classes-1bf903547236a473.yaml | 15 ++++ 4 files changed, 74 insertions(+), 32 deletions(-) create mode 100644 releasenotes/notes/resource-classes-1bf903547236a473.yaml diff --git a/doc/source/admin/upgrade-guide.rst b/doc/source/admin/upgrade-guide.rst index 1b9570d351..7a328a3e7e 100644 --- a/doc/source/admin/upgrade-guide.rst +++ b/doc/source/admin/upgrade-guide.rst @@ -42,7 +42,7 @@ Plan your Upgrade Upgrading from Ocata to Pike ============================ -#. It is recommended to set the ``resource_class`` field for nodes registered +#. It is required to set the ``resource_class`` field for nodes registered with the Bare Metal service *before* using the Pike version of the Compute service. See `enrollment documentation `_ diff --git a/doc/source/install/configure-compute.rst b/doc/source/install/configure-compute.rst index d8294f7b98..1d98dbf25d 100644 --- a/doc/source/install/configure-compute.rst +++ b/doc/source/install/configure-compute.rst @@ -56,11 +56,6 @@ service's controller nodes and compute nodes. #reserved_host_disk_mb=0 reserved_host_memory_mb=0 - # Flag to decide whether to use baremetal_scheduler_default_filters or not. - # (boolean value) - #scheduler_use_baremetal_filters=False - scheduler_use_baremetal_filters=True - # Determines if the Scheduler tracks changes to instances to help with # its filtering decisions (boolean value) #scheduler_tracks_instance_changes=True @@ -74,6 +69,21 @@ service's controller nodes and compute nodes. #scheduler_host_subset_size=1 scheduler_host_subset_size=9999999 + If you have not migrated to using :ref:`scheduling-resource-classes`, then + the following should be set as well: + + .. code-block:: ini + + [default] + + # Flag to decide whether to use baremetal_scheduler_default_filters or not. + # (boolean value) + #scheduler_use_baremetal_filters=False + scheduler_use_baremetal_filters=True + + This option is deprecated and has to be unset after migration + to resource classes. + #. Change these configuration options in the ``ironic`` section. Replace: diff --git a/doc/source/install/configure-nova-flavors.rst b/doc/source/install/configure-nova-flavors.rst index 2f8f3b2eae..4a9ac0e0c3 100644 --- a/doc/source/install/configure-nova-flavors.rst +++ b/doc/source/install/configure-nova-flavors.rst @@ -33,40 +33,32 @@ The flavor is mapped to the bare metal node through the hardware specifications. $ nova flavor-key my-baremetal-flavor set cpu_arch=$ARCH +.. _scheduling-resource-classes: + Scheduling based on resource classes ==================================== The Newton release of the Bare Metal service includes a field on the node resource called ``resource_class``. This field is available in version 1.21 of -the Bare Metal service API. +the Bare Metal service API. Starting with the Pike release, this field has +to be populated for all nodes, as explained in :doc:`enrollment`. -In the future (Pike or Queens release), a Compute service flavor will use this -field for scheduling, instead of the CPU, RAM, and disk properties defined in -the flavor above. A flavor will require *exactly one* of some bare metal +As of the Pike release, a Compute service flavor is able to use this field +for scheduling, instead of the CPU, RAM, and disk properties defined in +the flavor above. A flavor can request *exactly one* instance of a bare metal resource class. -This work is still in progress (see `blueprint -custom-resource-classes-in-flavors`), and the syntax for the ``flavor-create`` -call to associate flavors with resource classes is yet to be implemented. -According to the `custom resource classes specification`_, it will look -as follows: +To achieve that, the flavors, created as described in `Scheduling based on +properties`_, have to be associated with one custom resource class each. +A name of the custom resource class is the name of node's resource class, but +upper-cased, with ``CUSTOM_`` prefix prepended, and all punctuation replaced +with an underscore: .. code-block:: console $ nova flavor-key my-baremetal-flavor set resources:CUSTOM_=1 -where ```` is the resource class name in upper case with all -punctuation replaces with an underscore. - -For example, - -.. code-block:: console - - $ ironic --ironic-api-version=1.21 node-update $NODE_UUID \ - replace resource_class=baremetal.with-GPU - $ nova flavor-key my-baremetal-flavor set resources:CUSTOM_BAREMETAL_WITH_CPU=1 - -Another set of extra_specs properties will be used to disable scheduling +Another set of flavor properties should be used to disable scheduling based on standard properties for a bare metal flavor: .. code-block:: console @@ -75,9 +67,34 @@ based on standard properties for a bare metal flavor: $ nova flavor-key my-baremetal-flavor set resources:MEMORY_MB=0 $ nova flavor-key my-baremetal-flavor set resources:DISK_GB=0 -.. note:: - The last step will be required, as the Compute service will stop providing - standard resources for bare metal nodes. +.. warning:: + The last step will be mandatory in the Queens release, as the Compute + service will stop providing standard resources for bare metal nodes. -.. _blueprint custom-resource-classes-in-flavors: https://blueprints.launchpad.net/nova/+spec/custom-resource-classes-in-flavors -.. _custom resource classes specification: https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/custom-resource-classes-in-flavors.html +Example +------- + +If you want to define a class of nodes called ``baremetal.with-GPU``, start +with tagging some nodes with it: + +.. code-block:: console + + $ ironic --ironic-api-version=1.21 node-update $NODE_UUID \ + replace resource_class=baremetal.with-GPU + +.. warning:: + It is possible to **add** a resource class to ``active`` nodes, but it is + not possiblre to **replace** an existing resource class on them. + +Then you can update your flavor to request the resource class instead of +the standard properties: + +.. code-block:: console + + $ nova flavor-key my-baremetal-flavor set resources:CUSTOM_BAREMETAL_WITH_GPU=1 + $ nova flavor-key my-baremetal-flavor set resources:VCPU=0 + $ nova flavor-key my-baremetal-flavor set resources:MEMORY_MB=0 + $ nova flavor-key my-baremetal-flavor set resources:DISK_GB=0 + +Note how ``baremetal.with-GPU`` in the node's ``resource_class`` field becomes +``CUSTOM_BAREMETAL_WITH_GPU`` in the flavor's properties. diff --git a/releasenotes/notes/resource-classes-1bf903547236a473.yaml b/releasenotes/notes/resource-classes-1bf903547236a473.yaml new file mode 100644 index 0000000000..799d2320a2 --- /dev/null +++ b/releasenotes/notes/resource-classes-1bf903547236a473.yaml @@ -0,0 +1,15 @@ +--- +upgrade: + - | + Due to upcoming changes in the way Nova schedules bare metal nodes, all + nodes in a deployment using Nova have to get the ``resource_class`` field + populated before the upgrade. See `enrollment documentation + `_ + and `flavor configuration documentation + `_ + for details. + + Once you've migrated your flavors to resource classes, you should unset + the deprecated ``use_baremetal_filters`` option in the Compute service + configuration. Otherwise you'll be using the filters incompatible with + scheduling based on resource classes.