22.3. BasicStore -¶
The following documentation is for (BasicStore) content package at version 4.11.0.
22.3.1. Object Specific Documentation¶
22.3.1.1. params¶
The content package provides the following params.
22.3.1.1.1. boot-virtual-iso¶
Setting boot-virtual-iso to true, will enable the system to do virtual media iso boots for all bootenvs. When a bootenv changes, the machine will build a shim ISO that will be attached to the machine through IPMI and the system will be powercycled.
This requires the IPMI plugin to function properly.
22.3.1.1.2. bootenv-customize¶
This param allows you to overlay dynamic customizations on top of BootEnvs. Its intended use is to reduce the number of bootenvs you have to create for what are ultimately trivial reasons. This Param is structured as a map of bootenv name -> override values. The override values have the same names and semantics of the equivalent fields in the OS section of the BootEnv, with the following exceptions:
The Templates section is merged in with the Templates section from the BootEnv, with identically-named Templates from this Param overriding the ones from the BootEnv.
You must use the per-arch SupportedArchitectures section to override kernel, initrd, iso, boot parameter, and boot loader values from the BootEnv.
This feature is still in alpha, and this param definition and the semantics it enables may change. In particular, it is not compatible with bootenv purging right now, and you may experience UI pauses when uploading a new ISO file. You will also get unexpected results if you create multiple overrides for the same BootEnv that have the same OS name but reference different ISOs, or have different kernel/initrd settings. You should also not try to override Sledgehammer on a machine by machine basis, and any overrides for sledgehammer must be matched by identical changes in the OS section of the discovery bootenv.
22.3.1.1.3. bootloaders¶
dr-provision contains built-in support for various different bootloaders used for different machine and OS combinations. This param allows you to override the defaults either on a per-machine or global basis, unless a BootEnv overrides it with its Loaders field.
22.3.1.1.4. cron-trigger/time-string¶
The cron string uses the crontab standard 5 element string, all 5 elements are required separated by spaces.
Format is: [minute] [hour] [day of month] [month] [day of week]
22.3.1.1.5. decrypt/lookup-uri¶
LookupUri is combination of a plugin name and a path to where the secrets are stored. Defaults to “” which means local storage and ensures backwards compatibility. Example: “plugin://path?param1=val1¶m2=val2”
22.3.1.1.6. event-trigger/event-match¶
The scope.action.specific event to match for this event trigger.
22.3.1.1.7. event-trigger/event-object-match¶
If the await-style filter string is true, then it will considered a triggered event.
An example would be: Or(State=Eq(finished),State=Eq(failed),State=Eq(cancelled))
22.3.1.1.8. machine-self-runner¶
The parameter is used to indicate if the machine object is a self-runner for a DRP endpoint.
22.3.1.1.9. manager/password¶
The password the manager should use to access an endpoint
22.3.1.1.10. manager/url¶
The url the manager should use to access an endpoint
22.3.1.1.11. manager/username¶
The username the manager should use to access an endpoint
22.3.1.1.12. manager/version-set¶
The name of a version set to create from an endpoint
22.3.1.1.13. on-complete-delete¶
This parameter defines if the machine should be deleted once the current workflow completes.
To maintain backwards compatability, the parameter defaults to false.
22.3.1.1.14. on-complete-work-order-mode¶
This parameter defines if the machine should be moved to Work Order once the current workflow completes.
To maintain backwards compatability, the parameter defaults to false. This OVERRIDES on-complete-delete options.
22.3.1.1.15. on-delete-workflow¶
This parameter defines a workflow to run when the machine-like object is deleted. If specified, the machine will start this workflow, mark on-complete-delete, and return a success later response.
To maintain backwards compatability, there is not a default for this parameter.
22.3.1.1.16. pxelinux-local-boot¶
On most systems, using ‘localboot 0’ is the proper thing to do to have pxelinux try to boot off the first hard drive. However, some systems do not behave properly doing that, either due to firmware bugs or malconfigured hard drives. This param allows you to override ‘localboot 0’ with another pxelinux command. A useful reference for alternate boot methods is at https://www.syslinux.org/wiki/index.php?title=Comboot/chain.c32
22.3.1.1.17. static-lookaside¶
By default, dr-provision expects to be able to serve static files from a few different places in this order:
A dynamically rendered template file that has registered to be served from a particular path
A subdirectory that has been redirected to a remote server via the package-repositories parameter.
A different file pointed to by a template Link field.
A plain old local static file or directory
This parameter provides an additional customizable way transparently redirect to a remote HTTP server based on either boot environment name or directory path. It consists of a map of local resource: remote resource pairs that abide by the following rules:
If the local part begins with a /, it will be interpreted as a local directory starting at the static file server root. It will not be possible to escape from the static file server.
If the local part is exactly /, it is a general purpose override to refer all static file access to the corresponding remote resource, and the remote resource must start with http:// or https:// Be aware, the remote resource must have a copy of all the files dr-provision requires, and any local changes made by uploading files and isos will not be visible.
If the local resource does not begin with a /, it will be interpreted as if it was the name of a boot environment, and it will expand to the install paths using the same rules as {{ .Env.PathFor “tftp” }}. If the boot environment is not defined, it will be skipped. By default, this will only create a lookaside that is valid for the amd64 architecture. To specify lookasides for alternate architectures, name the local resource as bootenv-name/arch
If the remote resource begins with http:// or https://, then that URL will be used as the base URL for the lookaside. Otherwise, it will be appended to the remote resource of the ‘/’ local redirect and that constructed URL will be used as the base URL for the lookaside.
It is not permitted to have a remote resource that does not begin with http:// or https:// without a local / resource.
Example:
{ "/bob/modium": "https://mirrors.edge.kernel.org/centos", "centos-7-install": "https://mirrors.edge.kernel.org/centos/7/os/x86_64/", "centos-7-install/arm64": "http://mirror.centos.org/altarch/7/os/aarch64/" }
This directs dr-provision to transparently proxy any request on the static file server for /bob/modium (and any r esources under it) to https://mirrors.edge.kernel.org/centos, any requests for /centos-7/install/ to https://mirrors.edge.kernel.org/centos/7/os/x86_64/, and any requests to /centos-7/arm64/install to http://mirror.centos.org/altarch/7/os/aarch64/, assuming your centos-7-install boot environment comes from drp-community-content.
Redirects for Ubuntu installs should point to exploded Ubuntu install ISO files instead of package repository mirrors, as there are significant differences in the directory layout between the two from a a network boot and install perspecitve.
This functionality works for tftp requests and requests on port 8091, and dr-provision does not attempt to perform any request caching.
22.3.1.1.18. task-error-handlers¶
This map of tasks will be used to provide error handling tasks for task failure. When a task fails, the runner will be directed to run the listed tasks specified in the map for that task name. Task prerequisites will be added to the error task list. This might rerun already run tasks.
This will be capped to a depth of 1. Error failures are not handled can not be handled.
22.3.1.1.19. task-parameter-conversion¶
This parameter creates a key/value map of strings to convert parameters as tasks execute. The key is the parameter name to convert. The value looked up will be used for that parameter in all rendering actions. The lookup is recursive until the value is not in the map.
This parameter is composed and expanded when used by the renderer.
22.3.1.1.20. task-retry¶
This map of tasks or task action entries (e.g. action:ipmi-identify) will be used to cause the runner to automatically retry failures. A task will be retried up to the number times specified in the map. A simple exponential backoff starting at 2 seconds will be used between retries.
If more complex retry backoff is needed, use the error-handler functionality.
22.3.1.1.21. task-single-step¶
For debugging task lists and task operations, setting this variable to true will cause the system to set Runnable to false after each task.
22.3.1.1.22. task-skip¶
This list of tasks or task action entries (e.g. action:ipmi-identify) will be used to cause the runner to skip running them. A job will be created for tasks to indicate success with a message indicating that the job was skipped.
22.3.1.1.23. task-stop-at¶
This list of tasks or task action entries (e.g. action:ipmi-identify) will be used to cause the runner to stop before running them.
22.3.1.1.24. task-workflow-timeout¶
This map of workflow names will be used to act as a watchdog timer for workflows. If the map contains a workflow name, when the machine enters that workflow, a timer is started and if the workflow does not complete the workflow within that time, the machine will be rebooted. Times are specified in timer string syntax, e.g. 30m. The default unit is seconds.
22.3.1.1.25. task-workflow-timeout-restart¶
This singleton value can be used to set if the machine should restart the timeout after it triggers.
