Change flat network name for nosdn fdio scenario

[apex-tripleo-heat-templates.git] / puppet / services / README.rst

diff --git a/puppet/services/README.rst b/puppet/services/README.rst
index d55414b..38e2a28 100644 (file)
--- a/puppet/services/README.rst
+++ b/puppet/services/README.rst
@@ -99,12 +99,12 @@ 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:
 
-  * service_workflow_tasks: One or more workflow task properties
+  * 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::
 
-  service_workflow_tasks:
+  workflow_tasks:
     step2:
       - name: echo
         action: std.echo output=Hello
@@ -155,7 +155,7 @@ Similar to the step_config, we allow a series of steps for the per-service
 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.
 
@@ -186,6 +186,18 @@ Note that the services are not started in the upgrade tasks - we instead re-run
 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
 -----------------------------