openstack/tripleo-docs
Code Issues Proposed changes

Merge "Clarify profile matching documentation"

Browse Source
This commit is contained in:
Jenkins 2016-03-09 13:04:32 +00:00 committed by Gerrit Code Review
commit b9de8ae85b
1 changed files with 101 additions and 71 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

172
doc/source/advanced_deployment/profile_matching.rst
View File

@ -6,6 +6,10 @@ 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.
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.
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.
@ -18,33 +22,6 @@ from. It can be done either manually or using the introspection rules.
Do not miss the "boot_option" part from any commands below,
otherwise your deployment won't work as expected.
Create flavors to use profile matching
--------------------------------------
Default profile flavors should have been created when the undercloud was
installed, and they will be usable without modification in most environments.
However, if custom profile flavors are needed, they can be created as follows.
In order to use the profiles assigned to the Ironic nodes, Nova needs to have
flavors that have the property ``capabilities:profile`` set to the intended
profile.
For example, with just the compute and control profiles:
* Create the flavors::
openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 control
openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 compute
.. 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.
* Assign the properties::
openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="compute" compute
openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="control" control
Manual profile tagging
----------------------
@ -58,7 +35,7 @@ assigned profile (see `Use the flavors to deploy`_ for details). For example::
ironic node-update <UUID OR NAME> replace properties/capabilities=compute_profile:1,control_profile:1,boot_option:local
Finally, to clean all profile information from an available nodes, use::
Finally, to clean all profile information from a node use::
ironic node-update <UUID OR NAME> replace properties/capabilities=boot_option:local
@ -88,49 +65,9 @@ local hard drive size in GiB and RAM size in MiB. See
:ref:`introspection_data` for more details on what our current ramdisk
provides.
For example, imagine we have the following hardware: with disk sizes > 1 TiB
for object storage and with smaller disks for compute and controller nodes.
We also need to make sure that no hardware with seriously insufficient
properties gets to the fleet at all.
Create a JSON file, for example ``rules.json``, with the following contents::
[
{
"description": "Fail introspection for unexpected nodes",
"conditions": [
{"op": "lt", "field": "memory_mb", "value": 4096}
],
"actions": [
{"action": "fail", "message": "Memory too low, expected at least 4 GiB"}
]
},
{
"description": "Assign profile for object storage",
"conditions": [
{"op": "ge", "field": "local_gb", "value": 1024}
],
"actions": [
{"action": "set-capability", "name": "profile", "value": "swift"}
]
},
{
"description": "Assign possible profiles for compute and controller",
"conditions": [
{"op": "lt", "field": "local_gb", "value": 1024},
{"op": "ge", "field": "local_gb", "value": 40}
],
"actions": [
{"action": "set-capability", "name": "compute_profile", "value": "1"},
{"action": "set-capability", "name": "control_profile", "value": "1"}
]
}
]
.. note::
This example may need to be adjusted to work on a virtual environment.
Before introspection load this file into *ironic-inspector*::
Create a JSON file, for example ``rules.json``, with the introspection rules
to apply (see `Examples of introspection rules`_). Before the introspection
load this file into *ironic-inspector*::
openstack baremetal introspection rule import /path/to/rules.json
@ -145,6 +82,12 @@ If you've made a mistake in introspection rules, you can delete them all::
Then reupload the updated rules file and restart introspection.
.. note::
When you use introspection rules to assign the ``profile`` capability, it
will always override the existing value. On the contrary,
``<PROFILE>_profile`` capabilities are ignored for nodes with the existing
``profile`` capability.
Use the flavors to deploy
-------------------------
@ -185,5 +128,92 @@ 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
~~~~~~~~~
Imagine we have the following hardware: with disk sizes > 1 TiB
for object storage and with smaller disks for compute and controller nodes.
We also need to make sure that no hardware with seriously insufficient
properties gets to the fleet at all.
::
[
{
"description": "Fail introspection for unexpected nodes",
"conditions": [
{"op": "lt", "field": "memory_mb", "value": 4096}
],
"actions": [
{"action": "fail", "message": "Memory too low, expected at least 4 GiB"}
]
},
{
"description": "Assign profile for object storage",
"conditions": [
{"op": "ge", "field": "local_gb", "value": 1024}
],
"actions": [
{"action": "set-capability", "name": "profile", "value": "swift-storage"}
]
},
{
"description": "Assign possible profiles for compute and controller",
"conditions": [
{"op": "lt", "field": "local_gb", "value": 1024},
{"op": "ge", "field": "local_gb", "value": 40}
],
"actions": [
{"action": "set-capability", "name": "compute_profile", "value": "1"},
{"action": "set-capability", "name": "control_profile", "value": "1"},
{"action": "set-capability", "name": "profile", "value": null}
]
}
]
This example consists of 3 rules:
#. Fail introspection if memory is lower is 4096 MiB. Such rules can be
applied to exclude nodes that should not become part of your cloud.
#. Nodes with hard drive size 1 TiB and bigger are assigned the
``swift-storage`` profile unconditionally.
#. 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``
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
--------------------------------------
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.
* 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:boot_option"="local" --property "capabilities:profile"="my-profile" my-flavor
.. note::
The flavor name does not have to match the profile name, although it's
highly recommended.
.. _Introspection rules: http://docs.openstack.org/developer/ironic-inspector/usage.html#introspection-rules