22.45. task-library - Core Task Library¶

The following documentation is for Core Task Library (task-library) content package at version v4.12.0-alpha00.78+gc037aaa40eb3ad853690ce178f9ab8a5bae4c436.

This content package is a collection of useful stages and operations for Digital Rebar. It also includes several handy workflows like the CentOS base, Fedora base, and Ubuntu base workflows. You can also find many handy stages in this like the network-lldp stage which can be added to your discovery to add additional networking information discovered by lldp.

## Cluster Stages

These stages implement and augment Clusters.

Allows operators to orchestrate machines into sequential or parallel operation.

## Inventory Stage

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

22.45.1. Object Specific Documentation¶

22.45.1.1. blueprints¶

The content package provides the following blueprints.

22.45.1.1.1. alerts-on-content-change¶

This blueprint calls the same named task to to raise Alerts when a Content pack event is raised using the Triggers.

It requires that operators define an Event Trigger sets MergeData: true because the task relies on the Event meta data being passed as a param called meta.

Recommended Configuration:

`yaml MergeDataIntoParams: true Blueprint: alerts-on-content-change Params.event-trigger/event-match: contents.*.* Filter: Filter: "Params.cluster/tags=In(event-worker-pool) Endpoint=" FilterCount: 1 `

22.45.1.1.2. alerts-raise-from-events¶

This blueprint allows operators to raise alerts based on system events

22.45.1.1.3. ansible-apply¶

Uses ansible/playbook-templates to run playbook templates against a machine or cluster.

If the blueprint is run against a cluster, then all machines in the cluster will run the playbook templates remotely through SSH from a single ansible call. An inventory fill will be automatically execute.

If the blueprint is run against a machine or resource broker, the playbook will be run locally without SSH connection. The one exception to this is a machine with a Context. In this case, SSH will be attempted.

The Machine, WorkOrder, or Trigger using this blueprint must specify the playbook templates.

22.45.1.1.4. ansible-run-playbook-local-on-machine¶

Uses ansible-playbooks-local to run playbook(s) defined in Param ansible/playbooks in “local” mode on the selected machine(s).

Forces the ansible/connection-local to true.

There is a safe default so this can be used without a Param defined for testing.

22.45.1.1.5. cluster-reevaluate¶

This blueprint will cause the cluster-provision task to rerun on the cluster to pick up changes to the cluster.

22.45.1.1.6. cluster-run-blueprint-on-each-member¶

This is blueprint/trigger can used to run a blueprint on each member of a cluster.

This is an event trigger that requires the following parameters.

cluster/for-all-blueprint - defines the blueprint to run. cluster/for-all-cluster - defines the cluster to pull machines from.

This is an event trigger that can also use the following parameters.

cluster/for-all-profile - defines a profile to add to the WorkOrder for additional parameters.

The firing the trigger through event must contain the blueprint and cluster.

Applying the trigger/blueprint to a cluster requires the blueprint, but infers the cluster.

22.45.1.1.7. cost-calculator¶

Runs inventory-cost-calculator and inventory-cost-summation on the machines in question.

This can be used to regularly update/refresh the inventory/cost value for a machine, cluster or resource broker.

22.45.1.1.8. docker-context-run¶

This is a long running blueprint to run the docker-context plugin as a service.

To stop this blueprint, mark the machine running it as Not Runnable.

22.45.1.1.9. dr-server-add-content-from-git¶

This blueprint will check out a git repo, bundle the content. See the help on git-build-content-push for more details.

Based upon parameters, the system will put the content pack into the server or add the content pack to the catalog.

When used with the git-lab-trigger-webhook-push trigger, the repository param will be automatically populated when MergeData is set to true. This allows the webhook data to automically flow into the blueprint.

Generally, this blueprint runs from the DRP endpoint selfrunner and should use Params.cluster/tags=In(event-worker-pool) Endpoint= as a filter.

22.45.1.1.10. guacd-run¶

This is a long running blueprint to run guacd as a service.

To stop this blueprint, mark the resource_broker running it as Not Runnable.

22.45.1.1.11. manager-update-catalog¶

Runs the manager bootstrap work at some triggerable event. This is scheduled for nightly updates.

This can be used to regularly update/refresh the inventory/cost value for a machine, cluster or resource broker.

22.45.1.1.12. utility-endpoint-systems-check¶

This blueprint will performs basic diagnostic checks on a Digital Rebar endpoint to ensure healthy operation of the system

22.45.1.1.13. utility-update-ssh-keys¶

This blueprint will update the SSH keys set on the target machine using the ssh-access task

22.45.1.2. params¶

The content package provides the following params.

22.45.1.2.1. alert/cluster¶

Used by alerts, Params allows alert creators to provide useful back reference information.

In this instance, a backlink to the cluster is provided.

Dev Note: this is intended to be used by task developers when raising alerts from tasks. It does not influence configuration or behavior of an alert.

22.45.1.2.2. alert/content¶

Used by alerts, Params allows alert creators to provide useful back reference information.

In this instance, a backlink to the content is provided.

Dev Note: this is intended to be used by task developers when raising alerts from tasks. It does not influence configuration or behavior of an alert.

22.45.1.2.3. alert/job¶

Used by alerts, Params allows alert creators to provide useful back reference information.

In this instance, a backlink to the job is provided.

Dev Notes:

this is intended to be used by task developers when raising alerts from tasks. It does not influence configuration or behavior of an alert.

generally, use {{.CurrentJob}} to retrieve this information

22.45.1.2.4. alert/level¶

This operators to override the default level via Param in tasks that raise alerts.

For example, alerts-on-content-change uses the default value, but operators may define a WARN level by setting this value in the calling trigger.

22.45.1.2.5. alert/machine¶

Used by alerts, Params allows alert creators to provide useful back reference information.

In this instance, a backlink to the machine is provided.

Dev Notes:

this is intended to be used by task developers when raising alerts from tasks. It does not influence configuration or behavior of an alert.

generally, use {{.Machine.Name}} to retrieve this information

22.45.1.2.6. alert/source¶

Used when reposting alerts from events, allows event to identify a source

In this instance, a backlink to the task is provided.

Dev Note: this is intended to be used by task developers when raising alerts from tasks. It does not influence configuration or behavior of an alert.

22.45.1.2.7. alert/task¶

Used by alerts, Params allows alert creators to provide useful back reference information.

In this instance, a backlink to the task is provided.

Dev Note: this is intended to be used by task developers when raising alerts from tasks. It does not influence configuration or behavior of an alert.

22.45.1.2.8. alert/trigger¶

Used by alerts, Params allows alert creators to provide useful back reference information.

In this instance, a backlink to the content is provided.

Dev Notes:

this is intended to be used by task developers when raising alerts from tasks. It does not influence configuration or behavior of an alert.

genernerally use {{get .WorkOrder.Meta “triggered-by” }} to retrieve this information

22.45.1.2.9. alert/user¶

Used by alerts, Params allows alert creators to provide useful back reference information.

In this instance, a backlink to the task is provided.

Dev Note: this is intended to be used by task developers when raising alerts from tasks. It does not influence configuration or behavior of an alert.

22.45.1.2.10. alert/workorder¶

Used by alerts, Params allows alert creators to provide useful back reference information.

In this instance, a backlink to the workorder is provided.

Dev Note: this is intended to be used by task developers when raising alerts from tasks. It does not influence configuration or behavior of an alert.

22.45.1.2.11. alerts-bootstrap-handled¶

When the bootstrap error handler runs, it will make that it ran by setting this parameter to true. When the task is retried, it will so that it is already run and return to the original task to see if it can continue.

22.45.1.2.12. ansible-inventory¶

Holds the value from the ansible-inventory task.

22.45.1.2.13. ansible/connection-local¶

This parameter forces the ansible system to use localhost non-ssh ansible playbook execution.

22.45.1.2.14. ansible/output¶

Generic object that is constructed by the ansible-apply task if the playbook creates a file called [Machine.Name].json

For example, the following task will create the correct output:

```yaml - name: output from playbook

local_action:
module: copy content: “{{{{ myvar }}}}” dest: “{{ .Machine.Name }}.json”

```

22.45.1.2.15. ansible/playbook-templates¶

This is an array of strings where each string is a template that renders an Ansible Playbook. They are run in sequence to allow building inventory dynamically during a run.

Output from a playbook can be passed to the next one in the list by setting the ansible/output value. This value gets passed as a variable into the next playbook as part of the params on the machine object json.

22.45.1.2.16. ansible/playbooks¶

Used by Task ‘ansible-playbooks-local’ task.

Runs the provided playbooks in order from the json array. The array contains structured objects with further details about the ansible-playbook action.

Each playbook MUST be stored in either 1. a git location accessible from the machine running the task. 1. a DRP template accessible to the running DRP

The following properties are included in each array entry:

playbook (required): name of the playbooks passed into ansible-playbook cli

name (required): determines the target of the git clone

either (required, mutually exclusive):

repo: path related to machine where the playbook can be git cloned from

template: name of a DRP template containing a localhost ansible playbook

path (optional): if playbooks are nested into a single repo, move into that playbook

commit (optional): commit used to checkout a specific commit tag from the git history

data (optionalm boolean): if true, use items provided in args

args (optional): additional arguments to be passed into the ansible-playbook cli

verbosity (optional, boolean): if false, suppresses output from ansiblie using no_log.

extravars (optional, string): name of a template to expand as part of the extra-vars. See below.

For example

```json [

{
“playbook”: “become”, “name”: “become”, “repo”: “https://github.com/ansible/test-playbooks”, “path”: “”, “commit”: “”, “data”: false, “args”: “”, “verbosity”: true

}, {

“playbook”: “test”, “name”: “test”, “template”: “ansible-playbooks-test-playbook.yaml.tmpl”, “path”: “”, “commit”: “”, “data”: false, “args”: “”, “verbosity”: true

}

Using extravars allows pulling data from Digital Rebar template expansion into github based playbooks. These will show up as top level variables. For example:

`yaml foo: "{{ .Param "myvar" }}", bar: "{{ .Param "othervar" }"} `

22.45.1.2.17. bootstrap-download-contexts¶

This is an array of strings where each string is a context that should be downloaded / updated during the bootstrap-context task.

This is used by the bootstrapping system to add context images to the DRP Endpoint.

By default, no contexts are specified. If the operator sets this Param on the self-runner Machine object (either directly or via a Profile), then runs one of the bootstrap workflows, the context images will be installed.

This parameter is Composable and Expandable. This allows other profiles to incrementally and dynamically add to the list.

An example workflow is universal-bootstrap.

Example setting in YAML:

```yaml bootstrap-download-contexts:

drpcli-runner

context2

```

Or in JSON:

`json { "bootstrap-download-contexts": [ "drpcli-runner", "context2" ] } `

22.45.1.2.18. bootstrap-network-reservations¶

This Param can be set to an array of Reservation type objects. If it is added to the bootstrap-network profile, then during the bootstrap Stage, the defined reservations will be added to the system.

The easiest way to generate a valid reservation set of objects is to create the reservation on an existing DRP Endpoint, then show the JSON structure. An example CLI command reservation named 192.168.124.101 is shown below:

`sh drpcli reservations show 192.168.124.101 `

Multiple Subnets may be specified (eg drpcli reservations list; to dump all reservations on a given DRP Endpoint). Each Subnet will be added to the system if they do not exist already.

Example structures of two reservations is defined below. NOTE that in real world use, more options or values may need to be set to make the subnet operationally correct for a given environment.

YAML:

```yaml bootstrap-network-reservations:

Addr: 192.168.124.222 Token: “01:02:03:04:05:00”

Addr: 192.168.124.223 Token: “01:02:03:04:05:01”

```

JSON:

```json [

{ “Addr”: “192.168.124.222”, “Token”: “01:02:03:04:05:00” }, { “Addr”: “192.168.124.223”, “Token”: “01:02:03:04:05:01” }

Generally speaking this process is used for initial DRP Endpoint installation with the install.sh installation script. Preparing the Subnets and Reservations in either a Content Pack or a Profile that is applied to the system at installation time will enable the creation of the Objects.

Example installation script invocation that would use this bootstrap process, assumes that network.json is provided by the operator with the network Subnet and/or Reservations definitions:

`sh # you must create "network.json" which should be a valid Profile object, containing # the appropriate Params and object information in each param as outlined in the # examples in the bootstrap-network-subnets and boostrap-network-reservations # Params "Documentation" field curl -fsSL get.rebar.digital/stable | bash -s -- install --universal --initial-profiles="./network.json" `

22.45.1.2.19. bootstrap-network-subnets¶

This Param can be set to an array of Subnet type objects. If it is added to the bootstrap-network profile, then during the bootstrap Stage, the defined subnets will be added to the system.

The easiest way to generate a valid subnet object is to create the subnet on an existing DRP Endpoint, then show the JSON structure. An example CLI command for the subnet named kvm-test is shown below:

`sh drpcli subnets show kvm-test `

Multiple Subnets may be specified (eg drpcli subnets list; to dump all subnets on a given DRP Endpoint). Each Subnet will be added to the system if they do not exist already.

Example structures of two subnets is defined below.

!!! note

In real world use, more options or values may need to be set to make the subnet operationally correct for a given environment.

YAML:

```yaml - Subnet: 10.10.10.1/24

Name: subnet-10 ActiveEnd: 10.10.10.254 ActiveStart: 10.10.10.10 OnlyReservations: false Options: - Code: 1

Description: Netmask Value: 255.255.255.0

Code: 3 Description: DefaultGW Value: 10.10.10.1

Code: 6 Description: DNS Server Value: 1.1.1.1

Code: 15 Description: Domain Value: example.com

Subnet: 10.10.20.1/24 Name: subnet-20 ActiveEnd: 10.10.20.254 ActiveStart: 10.10.20.10 OnlyReservations: false Options: - Code: 1

Description: Netmask Value: 255.255.255.0
- Code: 3 Description: DefaultGW Value: 10.10.20.1
- Code: 6 Description: DNS Server Value: 1.1.1.1
- Code: 15 Description: Domain Value: example.com

```

JSON:

```json [

{
“Subnet”: “10.10.10.1/24”, “Name”: “subnet-10”, “ActiveEnd”: “10.10.10.254”, “ActiveStart”: “10.10.10.10”, “OnlyReservations”: false, “Options”: [

{ “Code”: 1, “Value”: “255.255.255.0”, “Description”: “Netmask” }, { “Code”: 3, “Value”: “10.10.10.1”, “Description”: “DefaultGW” }, { “Code”: 6, “Value”: “1.1.1.1”, “Description”: “DNS Server” }, { “Code”: 15, “Value”: “example.com”, “Description”: “Domain” }

]

}, {

“Subnet”: “10.10.20.1/24”, “Name”: “subnet-20”, “ActiveEnd”: “10.10.20.254”, “ActiveStart”: “10.10.20.10”, “OnlyReservations”: false, “Options”: [

{ “Code”: 1, “Value”: “255.255.255.0”, “Description”: “Netmask” }, { “Code”: 3, “Value”: “10.10.20.1”, “Description”: “DefaultGW” }, { “Code”: 6, “Value”: “1.1.1.1”, “Description”: “DNS Server” }, { “Code”: 15, “Value”: “example.com”, “Description”: “Domain” }

]

}

Generally speaking this process is used for initial DRP Endpoint installation with the install.sh installation script. Preparing the Subnets and Reservations in either a Content Pack or a Profile that is applied to the system at installation time will enable the creation of the Objects.

Example installation script invocation that would use this bootstrap process, assumes that network.json is provided by the operator with the network Subnet and/or Reservations definitions:

`sh # you must create "network.json" which should be a valid Profile object, containing # the appropriate Params and object information in each param as outlined in the # examples in the bootstrap--network-subnets and boostrap-network-reservations # Params "Documentation" field curl -fsSL get.rebar.digital/stable | bash -s -- install --universal --initial-profiles="./network.json" `

22.45.1.2.20. bootstrap-tools¶

This is an array of strings where each string is a package name for the base Operating System that is running on the DRP Endpoint, to be installed.

This is used by the bootstrapping system to add packages to the DRP Endpoint.

By default no packages are specified. If the operator sets this Param on the self-runner Machine object (either directly or via a Profile), then runs one of the bootstrap workflows, the packages will be installed.

An example workflow is universal-bootstrap.

Example setting in YAML:

```yaml bootstrap-tools:

package1

package2

```

Or in JSON:

`json { "bootstrap-tools": [ "package1", "package2" ] } `

22.45.1.2.21. broker-pool/allocate¶

If true (default), use the allocate/release methods when getting machines from the source pool. If false, use the add/remove methods when getting machines from the source pool

This flag allows operators to choose between pulling machines for multiple clusters from a shared pool (set to true) or creating new pools when using the Pool Broker (set to false) to create new clusters.

22.45.1.2.22. broker-pool/pool¶

The pool to pull machines from.

Will use default if not set.

22.45.1.2.23. broker/mach-name¶

The cluster gives a machine a name. This parameter tracks that name.

This is needed because the Pool Broker does not rename machines but to match the requested machine back to the actual machine allocated.

22.45.1.2.24. broker/name¶

The broker that provided these machines.

22.45.1.2.25. broker/pass-params-to-workorder¶

When cluster-provision task creates a work_order, these parameters will be included in that work_order.

If the Param is not defined for the cluster, then it will be skipped.

This allows pipeline developers to include needed information for the broker from the cluster data.

!!! note: The following params are always included and do not need to be added to this param: broker/. cluster/

22.45.1.2.26. broker/set-color¶

Color to use for broker/set-icon when creating machines using a broker.

22.45.1.2.27. broker/set-context¶

Sets the BaseContext to build machines with when using the broker-provision task.

Only applies for the Context Broker.

22.45.1.2.28. broker/set-icon¶

Icon to use when creating machines using a broker

Typical values:

aws: aws

azure: microsoft

default: cloud

google: google

linode: linode

digitalocean: digital ocean

oracle: database

22.45.1.2.29. broker/set-pipeline¶

When the broker creates machines, it assigns a pipeline to start during the join process. This will determine the operational path that the new machine follows.

This value sets the pipeline that will started when the machine is crated. Typically, the pipeline includes key configuration information and additional tasks to be injected during the configuration process.

22.45.1.2.30. broker/set-workflow¶

When the broker creates machines, it assigns a workflow to start during the join process. For cloud machines, this is typically universal-start (default). For physical machines, this is typically universal-discover.

For Pipelines, this value must be one of the chained workflow states; consequently, the typical values are universal-start and universal-discover.

22.45.1.2.31. broker/state¶

Generic object that is constructed by the brokers and stored on the broker machine to track general information.

22.45.1.2.32. broker/tfinfo¶

Generic object that is constructed by the brokers and stored on the broker machine to track terraform information.

22.45.1.2.33. broker/type¶

The broker type that provided these machines.

22.45.1.2.34. cloud/cost-lookup¶

Used by Task cloud-inventory to set cloud/cost.

This is intended for budgetary use only. Actual costs should be determined by inspecting the API for the cloud.

22.45.1.2.35. cloud/meta-apis¶

Used by Task ‘cloud-inventory’ and ‘cloud-detect-meta-api’ tasks.

Keys:

clouds is the ordered list of clouds to test during cloud-detect-meta-api

id is the field to use for the instance-id

apis is a dictionary per cloud that maps params to bash commands to retrieve the param

For each apis entry:

cloud/instance-id (required):

cloud/instance-type (optional):

cloud/placement/availability-zone (optional):

cloud/public-ipv4 (optional):

apis entries are bash commands that will yield the expected value when evalated at VAR=$([api command])

22.45.1.2.36. cluster/count¶

Used by cluster automation to determine the size of a cluster. More advanced clusters may use this field to define counts for workers in a multi-tiered cluster.

Defaults to 3. Set to 0 to drain the cluster.

This is used by v4.8+ cluster pipelines to build out the cluster size. Check the specific cluster for details about whehter it is used.

22.45.1.2.37. cluster/destroy¶

Used by cluster automation to destroy the cluster.

22.45.1.2.38. cluster/for-all-blueprint¶

Name of the blueprint to apply to all members of a cluster.

22.45.1.2.39. cluster/for-all-cluster¶

Name of the cluster to apply a blueprint to all members of a cluster.

22.45.1.2.40. cluster/for-all-profile¶

Name of a profile to apply to a blueprint to all members of a cluster.

22.45.1.2.41. cluster/machine-types¶

For v4.8 Cluster Pattern, this defines a list of machine types that will be added or removed by the plan.

22.45.1.2.42. cluster/machines¶

For v4.8 Cluster Pattern, this defines a map of machine types and their names. Each type can have additional parameters.

The purpose of this map is to uniquely identify the machines and allows the machines to be rotated in a controlled way.

If omitted the following items will be set via the designated Param:

pipeline: sets the initial pipeline or assigns from broker/set-pipeline [has safe default]

workflow: set the initial workflow or assigns from broker/set-workflow [has safe default]

icon: sets the initial Meta.icon or assigns from broker/set-icon [has safe default]

color: sets the initial Meta.color or assigns from broker/set-color [has safe default]

tags: [] but automatically includes cluster/profile

meta: meta data to set on the machine by cluster-add-params, if Meta.icon or Meta.color is set, it will over-write the icon/color.

Params: (note capitalization!): parameters to use in Terraform templates. Also set on machine during cluster-add-params

While most of these values are used only during terrafor-apply when building machines, meta and Params is used during cluster-add-params to update Meta and Params of the provisioned machines.

Example:

```yaml machine:

names:

cl_awesome_1

cl_awesome_2

cl_awesome_3

Params:
broker/set-workflow: universal-application-application-base broker/set-pipeline: universal-start broker/set-icon: server broker/set-color: black

```

22.45.1.2.43. cluster/profile¶

Name of the profile used by the machines in the cluster for shared information. Typically, this is simply self-referential (it contains the name of the containing profile) to allow machines to know the shared profile.

Note: the default value has been removed in v4.7. In versions 4.3-4.6, the default value was added to make it easier for operators to use clusters without having to understand need to create a cluster/profile value. While helpful, it leads to non-obvious cluster errors that are difficult to troubleshoot.

22.45.1.2.44. cluster/provision-kill-switch¶

Used as an emergency circuit breaker action to kill the cluster-provision Task during execution when in the machines await loop.

Set this Param to true to cause the next loop iteration to fail the task and stop processing.

22.45.1.2.45. cluster/provision-timeout¶

Used by cluster provision as a safety to determine how long to wait before failing the Task. By default this is set to 1 hour, and can be set to a user defined value in Seconds.

If set to -1, then no timeout evaluation will ever occur.

22.45.1.2.46. cluster/tags¶

For v4.8 Cluster Pattern, this defines tags added to the machine during construction by the broker.

22.45.1.2.47. cluster/use-single-wait¶

Flag to indicate that the cluster should do one wait

When true, the cluster will wait for the maximum timeout for the requested work order to complete. This can cause the the requesting task to appear hung.

If false, the cluster will loop using a 10 second wait period for requested work order(s) to complete.

22.45.1.2.48. cluster/wait-filter¶

The Task cluster-wait-for-members requires a filter condition to match a Machine object against to determine if the Machine has either succeeeded or failed the wait conditions.

By default the filter wait condition is set to:

Or(Runnable=Eq(false),WorkflowComplete=Eq(true))

For Clusters that utilize an OS installable Pipeline, the Machine objects will be set to Runnable: false when they reboot in to the OS Installer. in those cases; the cluster/wait-filter must be adjusted to not fail out when the Runnable: false condition is set (as expected).

For OS installable Pipelines the following filter MAY work. Future DRP versions may have better Machine fields to supporting this, rather than relying on overloading the Runnable field.

And(Workflow=Eq(universal-runbook),WorkflowComplete=Eq(true),BootEnv=Eq(local))

!!! note: The above filter assumes that universal-runbook is the final chained workflow in the Pipeline. This must be adjusted to be the correct final chained workflow.
!!! note: The above filter will NOT correctly catch a machine that failures out due to Workflow/Task errors setting the machine correctly to Runnable: false. The Pipeline/Workflow chains must succeed for the cluster to complete building.

22.45.1.2.49. cluster/wait-for-members¶

Used by cluster-provision task to inject cluster-wait-for-members into the cluster to be workflow complete.

Normally, pipeline designers can include cluster-wait-for-members one more more times in flexiflow, this Param provides a additional option to to make it built into cluster-provision.

22.45.1.2.50. context-broker/docker-context-version¶

Version of docker-context to use

22.45.1.2.51. context-broker/member-name¶

Used by docker-context to identify which system should create a machine

22.45.1.2.52. context-broker/tag¶

Used by broker-context-manipulate to find a machine to host containers

22.45.1.2.53. context-broker/tags¶

Used by manipulate-context-broker to distribute containers to members

22.45.1.2.54. context/container-info¶

Used by docker-context to provide details on the currently running container.

22.45.1.2.55. context/image-exists-counts¶

Used by docker-context to determine if an image already exists.

22.45.1.2.56. context/image-name¶

Used by docker-context for the name of the image.

22.45.1.2.57. context/image-path¶

Used by docker-context to provide the path in the local filestore for the image to upload.

22.45.1.2.58. context/name¶

Used by context-set as the target for the Param.BaseContext value.

Defaults to “” (Machine context)

22.45.1.2.59. dr-server/initial-password¶

Defaults to r0cketsk8ts

22.45.1.2.60. dr-server/initial-user¶

Defaults to multi-site-manager

22.45.1.2.61. dr-server/initial-version¶

The version DRP to install.

Typically: stable or tip, can also be a specific v4.x.x version from the RackN catalog.

This defaults to stable.

22.45.1.2.62. dr-server/install-drpid¶

If not set, will use site-[Machine.Name]

22.45.1.2.63. dr-server/install-license¶

If not set, it will attempt to update the current server’s license.

22.45.1.2.64. dr-server/skip-port-check¶

If true, includes the –skip-port-check flag during installation

This defaults to false.

22.45.1.2.65. dr-server/update-content¶

Boolean to indicate that the content should be updated.