Writing Tasks

Tasks are structurally very simple: they consist of a (YAML) metadata file, and any number of templates. Once you have automated the install for your operating system, for example, via kickstart or preseed, turning that into a task is a simple exercise in writing a bit of metadata and templating some of the things that your task does. Have a look at the stock tasks that ship with Razor to see some examples.

Tasks can either be stored in the file system or in the database. To get started, and especially while you are developing a task, you should only use tasks stored in the file system. The configuration setting task_path determines where in the file system Razor looks for tasks and can be a colon-separated list of paths. Relative paths in that list are taken to be relative to the toplevel Razor directory. For example, setting task_path to /usr/local/razor/tasks:/home/me/task:tasks will make Razor search these three directories in that order for tasks.

Task metadata

The following metadata entries can be in a task's YAML file, which must be called NAME.yaml where NAME is the task name.

---
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

Only os_version and boot_sequence must be provided. base allows deriving one task from another, by reusing some of its metadata and templates. Entries in the derived task's metadata override those in the base task's.

The boot_sequence hash indicates which templates to use when a node using this task boots: in the example, a node will first boot using boot_templ1, then using boot_templ2, and on every boot afterwards using boot_local.

Writing templates

Templates are ERB templates and are searched in all the directories given in the task_path configuration setting, in the subdirectories name/os_version, name, and finally common (in this order) If the task has a base task, the base tasks template directories are searched just before the common directory.

Templates can use the following helpers to generate URL's that point back to the server; all of them respond to a GET request, even the ones that make changes on the server:

• 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 PATH in the current repo
• log_url(MESSAGE, SEVERITY): the URL that will log MESSAGE in 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 VARS in 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: tell the server that we are done with this stage of the boot sequence, and that we should boot into the next one upon reboot.
• broker_install_url: a URL from which the install script for the node's broker can be retrieved. The os_complete.erb script, which is used by most tasks, contains an example.

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 into the same boot template over and over again.

The task must indicate to the Razor server that it has successfully finished its task by doing a GET request against stage_done_url("finished"), for example using curl or wget. This will mark the node as installed in the Razor database.

The way you use all these helpers is to cause your script to perform an HTTP GET 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.