Tasks describe a process or collection of actions that should be performed while Razor provisions machines. Tasks can be used to designate an operating system or other software that should be installed, where to get it, and the configuration details for the installation.
Tasks are structurally simple. They consist of a YAML metadata file and any number of ERB templates. You include the tasks you want to run in your policies (policies are described in the next section). The templates are used to generate things like the iPXE script that will boot a node into the installer, and automated installation files like kickstart, preseed or unattended files.
Razor provides a handful of existing tasks, or you can create your own. The existing tasks are primarily for installing supported operating systems.
Tasks are stored in the file system. The
task_path class parameter of the
pe_razor module determines where Razor looks for tasks. The parameter can include a colon-separated list of paths. Relative paths in that list are taken to be relative to the top-level Razor directory. For example, setting
/opt/puppet/share/razor-server/tasks:/home/me/task:tasks makes Razor search these three directories in that order for tasks.
There are two directories that store tasks:
/opt/puppetlabs/server/apps/razor-server/share/razor-server/tasksstores default tasks shipped with the product.
/etc/puppetlabs/razor-server/tasksstores custom tasks.
Tip: We recommend not modifying the directory or tasks at
/opt..., but you can copy tasks from there to the custom task directory and modify them as needed.
Tasks can include the following metadata in the task’s YAML file. This file
metadata.yaml and exists in
the task name. Therefore, the task name looks like this:
--- description: HUMAN READABLE DESCRIPTION os: OS NAME os_version: OS_VERSION_NUMBER base: TASK_NAME boot_sequence: 1: boot_templ1 2: boot_templ2 default: boot_local
boot_sequence are required. The
base key allows
you to derive one task from another by reusing some of the
and templates. If the derived task has metadata that’s different from the
base, the derived metadata overrides the base task’s
boot_sequence hash indicates which templates to use when a node using
this task boots. In the example above, a node will first boot using
boot_templ1, then using
boot_templ2. For every subsequent boot, the
node will use
Writing task templates
Task templates are ERB templates and are searched in all the directories
task_path configuration setting. Templates are searched in
the subdirectories in this order:
base.task# If the task has a base task.
Templates can use the following helpers to generate URLs that point back to
the server; all of the URLs respond to a
GET request, even the ones that
make changes on the server:
task: Includes attributes such as
node: Includes attributes such as
repo: Includes attributes such as
file_url(TEMPLATE): The URL that will retrieve
TEMPLATE.erb(after evaluation) from the current node’s task.
repo_url(PATH): The URL to the file at
PATHin the current repo.
log_url(MESSAGE, SEVERITY): The URL that will log
MESSAGEin the current node’s log.
node_url: The URL for the current node.
store_url(VARS): The URL that will store the values in the hash
VARSin the node. Currently only changing the node’s IP address is supported. Use
store_url("ip" => "192.168.0.1")for that.
stage_done_url: The URL that tells the server that this stage of the boot sequence is finished, and that the next boot sequence should begin upon reboot.
broker_install_url: A URL from which the install script for the node’s broker can be retrieved. You can see an example in the script, os_complete.erb, which is used by most tasks.
Each boot (except for the default boot) must culminate in something akin to
curl <%= stage_done_url %> before the node reboots. Omitting this will
cause the node to reboot with the same boot template over and over again.
The task must indicate to the Razor server that it has successfully
completed by doing a
GET request against
for example using
wget. This will mark the node
the Razor database.
You use these helpers by causing your script to perform an
against the generated URL. This might mean that you pass an argument like
ks=<%= file_url("kickstart")%> when booting a kernel, or that you put
curl <%= log_url("Things work great") %> in a shell script.