5) Service activation (Pacemaker)
+It is also possible to use Mistral actions or workflows together with
+a deployment step, these are executed before the main configuration run.
+To describe actions or workflows from within a service use:
+
+ * workflow_tasks: One or more workflow task properties
+
+which expects a map where the key is the step and the value a list of
+dictionaries descrbing each a workflow task, for example::
+
+ workflow_tasks:
+ step2:
+ - name: echo
+ action: std.echo output=Hello
+ step3:
+ - name: external
+ workflow: my-pre-existing-workflow-name
+ input:
+ workflow_param1: value
+ workflow_param2: value
+
+The Heat guide for the `OS::Mistral::Workflow task property
+<https://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Mistral::Workflow-prop-tasks>`_
+has more details about the expected dictionary.
+
Batch Upgrade Steps
-------------------
upgrade sequence, defined as ansible tasks with a tag e.g "step1" for the first
step, "step2" for the second, etc.
- Steps/tages correlate to the following:
+ Steps/tags correlate to the following:
1) Stop all control-plane services.
puppet which does any reconfiguration required for the new version, then starts
the services.
+Update Steps
+------------
+
+Each service template may optionally define a `update_tasks` key, which is a
+list of ansible tasks to be performed during the minor update process.
+
+Similar to the upgrade_tasks, we allow a series of steps for the per-service
+update sequence, but note update_task selects the steps via a conditional
+referencing the step variable e.g when: step == 2, which is different to the
+tags based approach used for upgrade_tasks (the two may be aligned in future).
+
+
Nova Server Metadata Settings
-----------------------------