Appendix C. Automatic Profile Tagging
The introspection process performs a series of benchmark tests. The director saves the data from these tests. You can create a set of policies that use this data in various ways. For example:
- The policies can identify and isolate underperforming or unstable nodes from use in the Overcloud.
- The policies can define whether to automatically tag nodes into specific profiles.
These policy files use a JSON format that contains a set of rules. Each rule defines a description, a condition, and an action.
Description
This is a plain text description of the rule.
Example:
"description": "A new rule for my node tagging policy"
Conditions
A condition defines an evaluation using the following key-value pattern:
- field
- Defines the field to evaluate.
- op
- Defines the operation to use for the evaluation. This includes the following:
eq- Equal tone- Not equal tolt- Less thangt- Greater thanle- Less than or equal toge- Greater than or equal toin-net- Checks that an IP address is in a given networkmatches- Requires a full match against a given regular expressioncontains- Requires a value to contain a given regular expression;is-empty- Checks that field is empty.
- invert
- Boolean value to define whether to invert the result of the evaluation.
- multiple
- Defines the evaluation to use if multiple results exist. This includes:
any- Requires any result to matchall- Requires all results to matchfirst- Requires the first result to match
- value
- Defines the value in the evaluation. If the field and operation result in the value, the condition return a true result. If not, the condition returns false.
Example:
"conditions": [
{
"field": "local_gb",
"op": "ge",
"value": 1024
}
],
Actions
An action is performed if the condition returns as true. It uses the
action key and additional keys depending on the value of action:
fail- Fails the introspection. Requires amessageparameter for the failure message.set-attribute- Sets an attribute on an Ironic node. Requires apathfield, which is the path to an Ironic attribute (e.g./driver_info/ipmi_address), and avalueto set.set-capability- Sets a capability on an Ironic node. Requiresnameandvaluefields, which are the name and the value for a new capability accordingly. The existing value for this same capability is replaced. For example, use this to define node profiles.extend-attribute- The same asset-attributebut treats the existing value as a list and appends value to it. If the optionaluniqueparameter is set to True, nothing is added if the given value is already in a list.
Example:
"actions": [
{
"action": "set-capability",
"name": "profile",
"value": "swift-storage"
}
]
Policy File Example
The following is an example JSON file (
rules.json) with the introspection rules to apply:
[
{
"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 three 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 Controller nodes. We assign two capabilities (
compute_profileandcontrol_profile) so that theopenstack overcloud profiles matchcommand 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.
Note
Using introspection rules to assign the
profile capability always overrides the existing value. However, [PROFILE]_profile capabilities are ignored for nodes with an existing profile capability.
Importing Policy Files
Import the policy file into the director with the following command:
$ openstack baremetal introspection rule import rules.json
Then run the introspection process.
$ openstack baremetal introspection bulk start
After introspection completes, check the nodes and their assigned profiles:
$ openstack overcloud profiles list
If you made a mistake in introspection rules, you can delete them all:
$ openstack baremetal introspection rule purge
Matching Nodes to Roles
To automatically assign a certain number of nodes to appropriate roles, use the
openstack overcloud profiles match command to specify how many nodes to assign to a certain role. For example, to automatically match three Controller nodes, three Compute nodes, and three Ceph Storage nodes, use the following command:
$ openstack overcloud profiles match --control-flavor control --control-scale 3 --compute-flavor compute --compute-scale 3 --ceph-storage-flavor ceph-storage --ceph-storage-scale 3
This assigns the nodes to appropriate roles based on the rules in the previously imported policy file.
Automatic Profile Tagging Properties
Automatic Profile Tagging evaluates the following node properties for the
field attribute of each condition:
|
Property
|
Description
|
|---|---|
memory_mb
|
The amount of memory for the node in MB.
|
cpus
|
The total number of cores for the node’s CPUs.
|
cpu_arch
|
The architecture of the node’s CPUs.
|
local_gb
|
The total storage space of the node’s root disk. See Section 5.4, “Defining the Root Disk for Nodes” for more information about setting the root disk for a node.
|
