Rework profile matching for direct provisioning
This change adds resource class matching and reworks profile matching to make no mention of image flavors or the deprecated profile commands. Change-Id: Ie3f820ad5d5449ae7f67aad70e329d986808c5ad
This commit is contained in:
Steve Baker
parent
211711ae81
commit
7c4ff6f931
|
|
@ -239,7 +239,7 @@ Each ``instances`` entry and the ``defaults`` dict support the following propert
|
|||
See :ref:`scaling-down`
|
||||
|
||||
* ``resource_class``: Selection criteria to match the node's resource class,
|
||||
defaults to ``baremetal``
|
||||
defaults to ``baremetal``. See :doc:`./profile_matching`
|
||||
|
||||
* ``root_size_gb``: Size of the root partition in GiB, defaults to 49
|
||||
|
||||
|
|
|
|||
|
|
@ -1,45 +1,62 @@
|
|||
(DEPRECATED)Advanced Profile Matching
|
||||
=====================================
|
||||
Node matching with resource classes and profiles
|
||||
================================================
|
||||
|
||||
.. note:: Flavor based scheduling is not supported since Wallaby as
|
||||
compute service is not used/available in the undercloud. However,
|
||||
one can still assign a profile to a node and use that for node
|
||||
filtering in `Baremetal Provision Configuration`_.
|
||||
The `Baremetal Provision Configuration`_ describes all of the instance and
|
||||
defaults properties which can be used as selection criteria for which node will
|
||||
be assigned to a provisioned instance. Filtering on the ``resource_class`` property
|
||||
is recommended for nodes which have special hardware for specific roles. The
|
||||
``profile`` property is recommended for other matching requirements such as
|
||||
placing specific roles to groups of nodes, or assigning instances to nodes based
|
||||
on introspection data.
|
||||
|
||||
Resource class matching
|
||||
-----------------------
|
||||
|
||||
Profile matching allows a user to specify precisely which nodes will receive
|
||||
which flavor. Here are additional setup steps to take advantage of the profile
|
||||
matching. In this document "profile" is a capability that is assigned to both
|
||||
ironic node and nova flavor to create a link between them.
|
||||
As an example of matching on special hardware, this shows how to have a custom
|
||||
``Compute`` role for PMEM equipped hardware, see :doc:`../features/compute_nvdimm`.
|
||||
|
||||
Default profile flavors ``compute``, ``control``, ``swift-storage``,
|
||||
``ceph-storage`` and ``block-storage`` are created when the undercloud is
|
||||
installed, and they are usable without modification in most environments.
|
||||
By default all nodes are assigned the ``resource_class`` of ``baremetal``. Each
|
||||
node which is PMEM enabled needs to have its ``resource_class`` changed to
|
||||
``baremetal.PMEM``::
|
||||
|
||||
After profile is assigned to a flavor, nova will only deploy it on ironic
|
||||
nodes with the same profile. Deployment will fail if not enough ironic nodes
|
||||
are tagged with a profile.
|
||||
baremetal node set <UUID OR NAME> --resource-class baremetal.PMEM
|
||||
|
||||
Assuming there is a custom role called ``ComputePMEM``, the
|
||||
``~/overcloud_baremetal_deploy.yaml`` file will match on ``baremetal.PMEM``
|
||||
nodes with:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
- name: ComputePMEM
|
||||
count: 3
|
||||
defaults:
|
||||
resource_class: baremetal.PMEM
|
||||
|
||||
Advanced profile matching
|
||||
-------------------------
|
||||
Profile matching allows a user to specify precisely which nodes provision with each
|
||||
role (or instance). Here are additional setup steps to take advantage of the
|
||||
profile matching. In this document ``profile`` is a capability that is assigned to
|
||||
the ironic node, then matched in the ``openstack overcloud node provision`` yaml.
|
||||
|
||||
After profile is specified in ``~/overcloud_baremetal_deploy.yaml``, metalsmith
|
||||
will only deploy it on ironic nodes with the same profile. Deployment will fail
|
||||
if not enough ironic nodes are tagged with a profile.
|
||||
|
||||
There are two ways to assign a profile to a node. You can assign it directly
|
||||
or specify one or many suitable profiles for the deployment command to choose
|
||||
from. It can be done either manually or using the introspection rules.
|
||||
|
||||
Manual profile tagging
|
||||
----------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To assign a profile to a node directly, issue the following command::
|
||||
|
||||
openstack baremetal node set <UUID OR NAME> --property capabilities=profile:<PROFILE>
|
||||
baremetal node set <UUID OR NAME> --property capabilities=profile:<PROFILE>
|
||||
|
||||
Alternatively, you can provide a number of profiles as capabilities in form of
|
||||
``<PROFILE>_profile:1``, which later can be automatically converted to one
|
||||
assigned profile (see `Use the flavors to deploy`_ for details). For example::
|
||||
To clean all profile information from a node use::
|
||||
|
||||
openstack baremetal node set <UUID OR NAME> --property capabilities=compute_profile:1,control_profile:1
|
||||
|
||||
Finally, to clean all profile information from a node use::
|
||||
|
||||
openstack baremetal node unset <UUID OR NAME> --property capabilities
|
||||
baremetal node unset <UUID OR NAME> --property capabilities
|
||||
|
||||
.. note::
|
||||
We can not update only a single key from the capabilities dictionary, so if
|
||||
|
|
@ -52,7 +69,7 @@ Also see :ref:`instackenv` for details on how to set profile in the
|
|||
.. _auto-profile-tagging:
|
||||
|
||||
Automated profile tagging
|
||||
-------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
`Introspection rules`_ can be used to conduct automatic profile assignment
|
||||
based on data received from the introspection ramdisk. A set of introspection
|
||||
|
|
@ -68,19 +85,18 @@ local hard drive size in GiB and RAM size in MiB. See
|
|||
provides.
|
||||
|
||||
Create a JSON file, for example ``rules.json``, with the introspection rules
|
||||
to apply (see `Examples of introspection rules`_). Before the introspection
|
||||
to apply (see `Example of introspection rules`_). Before the introspection
|
||||
load this file into *ironic-inspector*::
|
||||
|
||||
openstack baremetal introspection rule import /path/to/rules.json
|
||||
baremetal introspection rule import /path/to/rules.json
|
||||
|
||||
Then (re)start the introspection. Check assigned profiles or possible profiles
|
||||
using command::
|
||||
Then (re)start the introspection. Check assigned profiles using command::
|
||||
|
||||
openstack overcloud profiles list
|
||||
baremetal node list -c uuid -c name -c properties
|
||||
|
||||
If you've made a mistake in introspection rules, you can delete them all::
|
||||
|
||||
openstack baremetal introspection rule purge
|
||||
baremetal introspection rule purge
|
||||
|
||||
Then reupload the updated rules file and restart introspection.
|
||||
|
||||
|
|
@ -90,51 +106,8 @@ Then reupload the updated rules file and restart introspection.
|
|||
``<PROFILE>_profile`` capabilities are ignored for nodes with the existing
|
||||
``profile`` capability.
|
||||
|
||||
Use the flavors to deploy
|
||||
-------------------------
|
||||
|
||||
By default, all nodes are deployed to the **baremetal** flavor.
|
||||
To use profile matching you have to `Create flavors to use profile matching`_
|
||||
first, then use specific flavors for deployment. For each node role set
|
||||
``--ROLE-flavor`` to the name of the flavor and ``--ROLE-scale`` to the number
|
||||
of nodes you want to end up with for this role.
|
||||
|
||||
After profiles and possible profiles are tagged either manually or during
|
||||
the introspection, we need to turn possible profiles into an appropriate
|
||||
number of profiles and validate the result. Continuing with the example with
|
||||
only control and compute profiles::
|
||||
|
||||
openstack overcloud profiles match --control-flavor control --control-scale 1 --compute-flavor compute --compute-scale 1
|
||||
|
||||
* This command first tries to find enough nodes with ``profile`` capability.
|
||||
|
||||
* If there are not enough such nodes, it then looks at available nodes with
|
||||
``PROFILE_profile`` capabilities. If enough of such nodes is found, then
|
||||
their ``profile`` capabilities are updated to make the choice permanent.
|
||||
|
||||
This command should exit without errors (and optionally without warnings).
|
||||
|
||||
You can see the resulting profiles in the node list provided by
|
||||
|
||||
::
|
||||
|
||||
$ openstack overcloud profiles list
|
||||
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
|
||||
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
|
||||
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
|
||||
| 581c0aca-64f0-48a8-9881-bba3c2882d6a | | available | control | compute, control |
|
||||
| ace8ae8d-d18f-4122-b6cf-e8418c7bb04b | | available | compute | compute, control |
|
||||
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
|
||||
|
||||
Make sure to provide the same arguments for deployment later on::
|
||||
|
||||
openstack overcloud deploy --control-flavor control --control-scale 1 --compute-flavor compute --compute-scale 1 --templates
|
||||
|
||||
Examples of introspection rules
|
||||
-------------------------------
|
||||
|
||||
Example 1
|
||||
~~~~~~~~~
|
||||
Example of introspection rules
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Imagine we have the following hardware: with disk sizes > 1 TiB
|
||||
for object storage and with smaller disks for compute and controller nodes.
|
||||
|
|
@ -186,37 +159,30 @@ This example consists of 3 rules:
|
|||
|
||||
#. Nodes with hard drive less than 1 TiB but more than 40 GiB can be either
|
||||
compute or control nodes. So we assign two capabilities ``compute_profile``
|
||||
and ``control_profile``, so that the ``openstack overcloud profiles match``
|
||||
and ``control_profile``, so that the ``openstack overcloud node provision``
|
||||
command can later make the final choice. For that to work, we remove the
|
||||
existing ``profile`` capability, otherwise it will have priority.
|
||||
|
||||
#. Other nodes are not changed.
|
||||
|
||||
Create flavors to use profile matching
|
||||
--------------------------------------
|
||||
Provision with profile matching
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In most environment the pre-created profile flavors should be enough for use
|
||||
with profile matching. However, if custom profile flavors are needed,
|
||||
they can be created as follows.
|
||||
Assuming nodes have been assigned the profiles ``control_profile`` and
|
||||
``compute_profile``, the ``~/overcloud_baremetal_deploy.yaml`` can be modified
|
||||
with the following to match profiles during ``openstack overcloud node
|
||||
provision``:
|
||||
|
||||
* Create a flavor::
|
||||
|
||||
openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 my-flavor
|
||||
|
||||
.. note::
|
||||
The values for ram, disk, and vcpus should be set to a minimal lower bound,
|
||||
as Nova will still check that the Ironic nodes have at least this much.
|
||||
|
||||
* In order to use the profile assigned to the Ironic nodes, the Nova flavor
|
||||
needs to have the property ``capabilities:profile`` set to the intended
|
||||
profile::
|
||||
|
||||
openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:profile"="my-profile" my-flavor
|
||||
|
||||
.. note::
|
||||
The flavor name does not have to match the profile name, although it's
|
||||
highly recommended.
|
||||
.. code-block:: yaml
|
||||
|
||||
- name: Controller
|
||||
count: 3
|
||||
defaults:
|
||||
profile: control_profile
|
||||
- name: Compute
|
||||
count: 100
|
||||
defaults:
|
||||
profile: compute_profile
|
||||
|
||||
.. _Introspection rules: https://docs.openstack.org/ironic-inspector/usage.html#introspection-rules
|
||||
.. _Baremetal Provision Configuration: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/provisioning/baremetal_provision.html#baremetal-provision-configuration
|
||||
|
|
|
|||
Loading…
Reference in New Issue