Actions for existing roles¶

The deployment_tasks.yaml file contains tasks that define actions. The tasks that define actions execute on the existing roles.

Basic syntax for a task definition:

- id: <task id>
  type: <type of task>
  groups: [<one or more of existing roles>]
  required_for: [<the list of tasks, which requires this one>]
  requires: [<the list of tasks, which a required for this one>]
  parameters:
   <parameter name>: <parameter value>
   ...

Examples

We will provide examples of tasks that define actions. We will also provide examples of how to test the tasks.

We will list possible keyword values for reference.

Prerequisites

• A deployed Fuel environment with one controller node and one compute node.
• A plugin enabled in the environment settings.

You can make live changes to the plugin’s deployment tasks, as this is much faster to test the changes this way rather than do the full environment reinstallation for every task change.

To make it simple, we will delete the automatically generated tasks.yaml and deployment_tasks.yaml files. We will create a new deployment_tasks.yaml from scratch.

Add a task to execute shell commands:

- id: fuel-plugin-example-iotop
  type: shell
  role: '*'
  requires: [post_deployment_start]
  required_for: [post_deployment_end]
  parameters:
  cmd: apt install iotop && echo `date` ' iotop installed' >>
  /tmp/post_deployment || echo `date` ' failed to install iotop'
  >> /tmp/post_deployment

Then sync the plugin tasks, execute the newly defined one, and verify the results:

# fuel plugins --sync
# fuel node  --nodes 1,2 --tasks fuel-plugin-example-iotop
# ssh node-1 "cat  /tmp/post_deployment;  iotop --version"
Fri May 20 12:48:08 UTC 2016  iotop installed
iotop 0.6

The task in the example executes the shell commands listed in the parameter cmd: the task installs the package iotop on all the nodes in the environment; or, in our test, in the subset listed after the key ‘–nodes’. Pay attention to the parameters requires and required_for: they define when exactly during installation the task will run and are required for the task execution. The task will usually run in the post-deployment stage, but in our example we forced it to run alone. After the task execution, you can use the command iotop to monitor the I/O on the environment nodes.

In our example, we used the asterisk ‘*’ as the value for the keyword role. To run the tasks only on particular roles, but not the others, replace the value with the list of roles on which to run; for example:

role: [ primary-controller, controller, compute]

Our example task with the commands listed in the cmd parameter is not suitable for more than two shell commands; but we always can put the commands in a shell script and call the script instead:

parameters:
 cmd: bash install_iotop.sh

Put the script install_iotop.sh in the subdirectory deployment_scripts in plugin root. If you run the plugin task, the result will be the same as in the previous case, when we defined all the commands in deployment_tasks.yaml.

The mechanism behind this is as follows. Before the plugin task runs, all the files inside the plugin root are synced by rsync protocol to the directory /etc/fuel/plugins/<plugin name> on target nodes. This directory is set as the default working directory for plugin tasks – although you can override it by specifying the explicit cwd parameter for the task, so the command bash install_iotop.sh will run the script from it.

Considering that deployment scripts are copied to target nodes before any of the tasks run, you can skip the step for syncing tasks if you only change the contents of the deployment scripts in the process of debugging and run the tasks directly after the changes.

You can use any script language or executable as long as they can be called from shell, but Puppet is the most common tool to write Fuel plugins and there is support for Puppet tasks.

Let us rewrite the same task using Puppet manifests.

deployment_tasks.yaml:

- id: fuel-plugin-example-iotop
  type: puppet
  role: '*'
  requires: [post_deployment_start]
  required_for: [post_deployment_end]
  parameters:
   puppet_manifest: puppet/manifests/install_iotop.pp
   puppet_modules: puppet/modules:/etc/puppet/modules

deployment_scripts/puppet/manifests/install_iotop.pp:

notice('MODULAR: fuel-plugin-example/iotop')

package { 'iotop':
  ensure => 'installed',
}

We changed the type attribute of the deployment task to puppet and replaced the cmd parameter with the two Puppet specific ones: puppet_manifest and puppet_modules. If you are familiar with Puppet, these parameters are self-explanatory. The values of the parameters are path specifications relative to the deployment_scripts directory in plugin root. Follow the standard Puppet conventions and keep Puppet manifests in modules in separate subdirectories. In our example we are using no modules, but in any other not so trivial case it is good to keep the code modular. The parameter puppet_modules is required.

notice('MODULAR: fuel-plugin-example/iotop')

Related links

See also Deployment Tasks on Fuel Wiki.