Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

Appendix E. 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.

E.1. Policy File Syntax

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. For field types, see Section E.4, “Automatic Profile Tagging Properties”
op

Defines the operation to use for the evaluation. This includes the following:

  • eq - Equal to
  • ne - Not equal to
  • lt - Less than
  • gt - Greater than
  • le - Less than or equal to
  • ge - Greater than or equal to
  • in-net - Checks that an IP address is in a given network
  • matches - Requires a full match against a given regular expression
  • contains - 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 match
  • all - Requires all results to match
  • first - 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 a message parameter for the failure message.
  • set-attribute - Sets an attribute on an Ironic node. Requires a path field, which is the path to an Ironic attribute (e.g. /driver_info/ipmi_address), and a value to set.
  • set-capability - Sets a capability on an Ironic node. Requires name and value fields, 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 as set-attribute but treats the existing value as a list and appends value to it. If the optional unique parameter 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"
  }
]

E.2. 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 than 4096 MiB. Such rules can be applied to exclude nodes that should not become part of your cloud.
  • Nodes with a hard drive size 1 TiB and bigger are assigned the swift-storage profile unconditionally.
  • Nodes with a hard drive less than 1 TiB but more than 40 GiB can be either Compute or Controller nodes. 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.

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.

E.3. 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 overcloud node introspect --all-manageable

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

E.4. Automatic Profile Tagging Properties

Automatic Profile Tagging evaluates the following node properties for the field attribute for each condition:

PropertyDescription

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 6.6, “Defining the root disk” for more information about setting the root disk for a node.