Requirement types¶

These are the supported members of the Requires (mapped) property. You can use any number or combination of these within a requires definition, optionally using a LogicalGroupings for logical groupings.

Path¶

This has the same format as the input property and is used to assert if a path exists or not. Note that all-logs is not applied to the path.

Usage:

path: <path>

Cache keys:

path_not_found - the first path not found, or None.
paths - list of resolved paths provided.

Property¶

Imports a Python property and applies one or more operators to its value to get a boolean result. By default, Python’s operator.truth is applied.

Usage:

property: <import path to python property>

property:
  path: <import path to python property>
  ops: [[<operator>, <optional argument>], ...]

Cache keys:

ops - list of operators applied to property value

property - import path

value_actual - value of property

Apt¶

Takes an apt package name and optional list of version ranges. Returns True if the package exists and if provided, version is within ranges.

Usage:

apt: mypackage

Or with version ranges as follows:

apt:
  mypackage:
    - min: 0.0
      max: 1.0
    - min: 4.0
      max: 5.0

In the above example mypackage must have a version between 0.0 and 1.0 or 4.0 and 5.0 inclusive.

Another example:

apt:
  mypackage:
    - gt: 1.0
      lt: 3.0
    - eq: 5.0.3

In the above example mypackage must have a version between 1.0 and 3.0 (non-inclusive), or specifically 5.0.3.

Supported operators:

eq - equality comparison

lt - less than (<)

gt - greater than (>)

le/max - less than or equal (<=)

ge/min - greater than or equal (>=)

Cache keys:

package - comma-separated string of installed package names.
version - comma-separated string of their installed versions.

Binary¶

Takes a binary name and optional list of version ranges. Returns True if the binary exists and if provided, version is within ranges.

Usage:

binary:
  name: mybin
  handler: path.to.handler

Or with version ranges as follows:

binary:
  handler: path.to.bininterfacehandler
  mybin:
    - min: 0.0
      max: 1.0
    - min: 4.0
      max: 5.0

NOTE: the version checking logic is currently the same as for the Apt type.

Cache keys:

binary - comma-separated string of installed binary names.
version - comma-separated string of their installed versions.

Snap¶

Takes a snap package name and optional list of revision, version and channel. The check returns True if the package is installed and at least one of the r/v/c combination evaluates to True.

Usage:

snap: mypackage

Or with optional conditions as follows:

snap:
  mypackage:
    - revision:
        min: 1234
        max: 2345
      channel: 2.0/stable
    - version:
        eq: 1.17
    - channel: 3.0/beta

In the above example in order for snap requirement to be True, mypackage snap must be installed in the system and either one of the following conditions must be true:

revision number is between 1234-2345 and the channel name is exactly 2.0/stable
version number is 1.17
channel name is exactly 3.0/beta

All criteria in one list item must match (AND). Matching any list item is sufficient (OR).

Cache keys:

channel - comma-separated string of installed package channels.
package - comma-separated string of installed package names.
revision - comma-separated string of installed package revisions.
version - comma-separated string of installed package versions.

Pebble¶

Takes a pebble service name and optional parameters to check. Returns True if the service exists and, if provided, parameters match. Short and long forms are supported as follows.

Usage:

pebble: <service name>  (state not checked here)

pebble: [svc1, svc2 ...]  (state not checked here)

pebble:
  service_name: active

pebble:
  service_name:
    state: <service state>
    op: <python operator>  (optional. default is 'eq')
    processes: list of processes we expect to be running  (optional)

Cache keys:

services - comma-separated string of service names checked.

Systemd¶

Takes a systemd service name and optional parameters to check. Returns True if the service exists and, if provided, parameters match. Short and long forms are supported as follows.

If a service name is provided using the started-after parameter, the start time of that service (if it exists) must be at least 120s behind the primary service. The grace period is to avoid false-positives on boot where many services are often started at once.

The following example shows the simplest form whereby only a service name is provided. This returns True if the service exists but does not check state.

systemd: <service name>

A list of service names can also be provided. The first service found not to exist causes it to return False.

systemd: [svc1, svc2 ...]  (state not checked here)

This next example shows a more thorough check:

systemd:
  service_name: active

The mapping shorthand above checks that the service state equals active. The expanded form supports additional criteria:

systemd:
  service_name:
    op: eq
    processes: ['aproc']
    started-after: anotherservice
    state: active

Here we check that the service exists, has state == “active” (as per the op field that can be any suitable python operator), was started after service anotherservice and has a running process called “aproc”.

NOTE: when using this form, at least one field must be set.

Cache keys:

services - comma-separated string of service names checked.

Config¶

Perform config checks by applying assertion rules to the contents of config file. Assertions are defined as a list that is grouped as a LogicalGroupings with AND as the default grouping. The final result evaluates to True/False. Makes use of config “handlers” i.e. implementations of core.host_helpers.config.IniConfigBase that support querying the contents of config files in a common way.

Usage:

config:
  handler: <import path>
  path: <path to config file>
  assertions:
    - allow-unset: <bool>
      key: <str>
      ops: <list>
      section: <str>
      value: <str> or <bool>

The value of key can be checked by either providing a value to which it is compared or by setting ops to a list of operations. Only one of value and ops should be used to check a value.

Optional parameter allow-unset defaults to false and determines whether the assertion passes when the key is unset or not found.

NOTE: path must be relative to the data root.

Example:

checks:
  checkcfg:
    config:
      handler: hotsos.core.plugins.openstack.OpenstackConfig
      path: etc/nova/nova.conf
      assertions:
        - key: debug
          ops: [[eq, true]]
          section: DEFAULT

Cache keys:

assertion_results - string of concatenated assertion checks
key - the last key to be checked
ops - the last ops to be run
value_actual - the value of the last key to be checked

Varops¶

This provides a way to define a list of operations to be executed in sequence. Each operation is defined as a tuple of size one or two. The first operation acts as the input and is defined as a singleton of one variable (see vars). Successive operations take as input the output of the previous operation and are defined as one or two tuple objects where the first element is a python operator and the optional second element is an argument as required by the operator.

Usage:

vars:
  myvar: 10
  limit: 5
checks:
  checkmyvar:
    varops: [[$myvar], [gt, $limit], [lt, 100]]

Cache keys:

input_ref: name of the variable used as input
input_value: value of the variable used as input
ops: str representation of ops list