26.35. task-library

The following documentation is for task-library content package at version v1.13.3-0-4d14a648bbe323738514cbc9958f1a25f4678be8.

26.36. RackN Task Library

This content package is used to collect useful stages and operations for Digital Rebar.

26.36.1. Cluster Stages

These stages implement the Multi-Machine Cluster Pattern.

Allows operators to orchestrate machines into sequential or parallel operation.

26.36.2. Inventory Stage

Convert gohai and other JSON data into a map that can be used for analysis, classification or filtering.

26.36.3. params

The content package provides the following params.

26.36.3.1. inventory/check

Using BASH REGEX, define a list of inventory data fields to test using Regular Expressions. Fields are tested in sequence, the first to fail will halt the script

26.36.3.2. inventory/CPUCores

From inventory/data, used for indexable data

26.36.3.3. inventory/collect

Map of commands to run to collect Inventory Input Each group includes the fields with jq maps to store For example: adding “drpcli gohai” will use gohai JSON as input Then jq will be run with provided values to collect inventory into a inventory/data as a simple map.

To work correctly, Commands should emit JSON

Special Options:
  • Change the command to parse JSON from other sources
  • Add JQargs to give hints into jq arguments before the parse string
Gohai example:
::
{
gohai: {

Command: “drpcli gohai”, JQargs: “” Fields: {

RAM: “.System.Memory.Total / 1048576 | floor”, NICs: “.Networking.Interfaces | length”

}

}

}

26.36.3.4. inventory/flatten

Creates each inventory value as a top level Params This is needed if you want to filter machines in the API by inventory data. For example, using Terraform filters. WARNING: This will create LOTS of Params on machines!

26.36.3.5. inventory/CPUType

From inventory/data, used for indexable data

26.36.3.6. inventory/ProductName

From inventory/data, used for indexable data

26.36.3.7. inventory/data

Stores the data collected by the fieds set in inventory/collect If inventory/integrity true, then used for comparision data

26.36.3.8. inventory/CPUs

From inventory/data, used for indexable data

26.36.3.9. inventory/NICs

From inventory/data, used for indexable data

26.36.3.10. inventory/Family

From inventory/data, used for indexable data

26.36.3.11. inventory/Manufacturer

From inventory/data, used for indexable data

26.36.3.12. inventory/RAM

From inventory/data, used for indexable data

26.36.3.13. inventory/integrity

Allows operators to compare new inventory/data to stored inventory/data on the machine. If true and values not match (after first run) then Stage will fail

26.36.3.14. ansible-inventory

Ansible inventory facts as gathered by ansible.

This provides an untyped dictionary of values from Ansible.

NOTE: This is raw data. Other parameters can be distilled from this.

26.36.3.15. inventory/CPUSpeed

From inventory/data, used for indexable data

26.36.3.16. inventory/SerialNumber

From inventory/data, used for indexable data

26.36.3.17. drive-signatures

A map of drive to SHA1 signatures.

26.36.4. stages

The content package provides the following stages.

26.36.4.1. drive-signature

Builds a signature for each drive and stores that on the machine.

26.36.4.2. ansible-inventory

Collects ansible inventory data from ansible’s setup module.

26.36.4.3. drive-signature-verify

Verifies signatures for drives.

26.36.4.4. inventory

Collects selected fields from Gohai into a simpler, flat list. The process uses JQ filters, defined in inventory/fields, to build inventory/data on each machine. Also, applies the inventory/check map to the data and will fail if the checks do not pass.

26.36.5. tasks

The content package provides the following tasks.

26.36.5.1. cluster-step

Waits until machine is in Nth (or earlier) position Replies on cluster-remove to advance queue Typical cluster workflow is add->step->remove->sync Where step or sync are optional. See cluster-add task for more details

26.36.5.2. drive-signature

Generate a signature for each drive and record them on them machine.

26.36.5.3. drive-signature-verify

Using the signatures on the machine, validate each drive’s signature matches.

26.36.5.4. ansible-inventory

Install ansible, if needed, and record the setup module ansible variables onto the machine as parameter, ansible-inventory.

26.36.5.5. cluster-add

Injects the Machine Uuid into the cluster/machines param. This is the first step in a the cluster workflow Typical cluster workflow is add->step->remove->sync Where step or sync are optional.

The cluster-* stages provide basic queue management for machines with a shared profile. That profile must have a cluster/profile field that names the profile. Once the queue is running, machines are tracked in the cluster/machines parameter.

cluster-add enqueues the machine cluster-step services the queue (takes the next cluster/step in line) cluster-remove dequeues the machine (should be done AFTER servicing) cluster-sync forces all machines to wait until the queue is empty

If you are doing a rolling upgrade, use the following sequence: cluster-add -> cluster-step -> [do work] -> cluster-remove

If you are coalescing work over multiple machines, use the following sequence: cluster-add -> [do work] -> cluster-remove -> cluster-sync

The cluster-add process will automatically elect cluster/leader-count leaders during the enqueue step. These cluster/leaders will be be maintained after the run is over and require manual editing to remove. It is possible to pre-create the leasder list.

It is possible to do multiple add/remove steps in a single workflow

If your cluster is NOT behaving, you can rescue or escape from the cluster stages by setting cluster/escape on the profile. This will interrupt a cluster in process. Using escape=0 will allow the cluster stages to exit normally and noop while using escape=1 will exit with an error and the stages will stop progressing. Escape=1 is safter since downstream actions are blocked.

26.36.5.6. cluster-remove

Removes the Machine Uuid into the cluster profile Typical cluster workflow is add->step->remove->sync Where step or sync are optional. See cluster-add task for more details

26.36.5.7. cluster-sync

Waits until no machines remain. Use with cluster-remove Typical cluster workflow is add->step->remove->sync Where step or sync are optional. See cluster-add task for more details

26.36.5.8. inventory-check

Using the inventory/collect parameter, filters the JSON command output into inventory/data hashmap for rendering and validation. Will apply inventory/check for field valation

26.36.5.9. network-lldp

Assumes Sledgehammer has LLDP daemon installed so that we can collect data. Also requires the system to have LLDP enabled on neighbors including switches to send the correct broadcast packets.

26.36.5.10. stage-chooser

This task uses the stage-chooser/next-stage and stage-chooser/reboot parameters to change the stage of the current machine and possibly reboot.

This is not intended for use in a stage chain or workflow. But a transient stage, that can be used on a machine that is idle with a runner executing.

26.36.6. workflows

The content package provides the following workflows.

26.36.6.1. centos-base

This workflow includes the DRP Runner in CentOS provisioning process for DRP.

After the install completes, the workflow installs the runner in a waiting state so that DRP will automatically detect and start a new workflow if the Machine.Workflow is updated.

NOTE: To enable, upload the CentOS ISO as per the centos-7 BootEnv

26.36.6.2. ubuntu-base

This workflow includes the DRP Runner in Ubuntu provisioning process for DRP.

After the install completes, the workflow installs the runner in a waiting state so that DRP will automatically detect and start a new workflow if the Machine.Workflow is updated.

NOTE: To enable, upload the Ubuntu-18.04 ISO as per the ubuntu-18.04 BootEnv