Chapter 18. Configuring 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:

  • The policies can identify underperforming or unstable nodes and isolate these nodes from use in the overcloud.
  • The policies can define whether to tag nodes into specific profiles automatically.

18.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:

  • memory_mb - The amount of memory for the node in MB.
  • cpus - The total number of threads for the node CPU.
  • cpu_arch - The architecture of the node CPU.
  • local_gb - The total storage space of the node’s root disk.
op

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

  • 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 parameter includes the following attributes:

  • 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. Otherwise, the condition returns a false result.

Example:

"conditions": [
  {
    "field": "local_gb",
    "op": "ge",
    "value": 1024
  }
],

Actions

If a condition is ‘true’, the policy performs an action. The action 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. 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"
  }
]

18.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. You can apply these types of rules if you want to exclude certain nodes from 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. You can assign two capabilities (compute_profile and control_profile) so that the openstack overcloud profiles match command can later make the final choice. For this process to succeed, you must remove the existing profile capability, otherwise the existing profile capability has priority.

The profile matching rules do not change any other nodes.

Note

Using introspection rules to assign the profile capability always overrides the existing value. However, [PROFILE]_profile capabilities are ignored for nodes that already have a profile capability.

18.3. Importing policy files

To import policy files to the director, complete the following steps.

Procedure

  1. Import the policy file into the director:

    $ openstack baremetal introspection rule import rules.json
  2. Run the introspection process:

    $ openstack overcloud node introspect --all-manageable
  3. After introspection completes, check the nodes and their assigned profiles:

    $ openstack overcloud profiles list
  4. If you made a mistake in introspection rules, run the following command to delete all rules:

    $ openstack baremetal introspection rule purge