X-Git-Url: https://gerrit.opnfv.org/gerrit/gitweb?a=blobdiff_plain;f=puppet%2Fservices%2FREADME.rst;h=38e2a28076fb8e6526741ffe13710a679cf91c72;hb=refs%2Fheads%2Fmaster;hp=0fb1da6545c7ab5c4a2f68a6deb451d7b96b2f5b;hpb=16cae1759fe5606d15a33d31f962ca757f499e1e;p=apex-tripleo-heat-templates.git

diff --git a/puppet/services/README.rst b/puppet/services/README.rst
index 0fb1da65..38e2a280 100644
--- a/puppet/services/README.rst
+++ b/puppet/services/README.rst
@@ -19,21 +19,35 @@ environment to set per service parameters.
 Apart from sevice specific inputs, there are few default parameters for all
 the services. Following are the list of default parameters:
 
- * ServiceNetMap: Mapping of service_name -> network name. Typically set via
-   parameter_defaults in the resource registry.  This mapping overrides those
-   in ServiceNetMapDefaults.
+ * ServiceNetMap: Mapping of service_name -> network name. Default mappings
+   for service to network names are defined in
+   ../network/service_net_map.j2.yaml, which may be overridden via
+   ServiceNetMap values added to a user environment file via
+   parameter_defaults.
 
- * EndpointMap: Mapping of service endpoint -> protocol. Typically set via
-   parameter_defaults in the resource registry.
+ * EndpointMap: Mapping of service endpoint -> protocol. Contains a mapping of
+   endpoint data generated for all services, based on the data included in
+   ../network/endpoints/endpoint_data.yaml.
 
- * DefaultPasswords: Mapping of service -> default password. Used to help pass
-   top level passwords managed by Heat into services.
+ * DefaultPasswords: Mapping of service -> default password. Used to pass some
+   passwords from the parent templates, this is a legacy interface and should
+   not be used by new services.
 
  * RoleName: Name of the role on which this service is deployed. A service can
-   be deployed in multiple roles.
+   be deployed in multiple roles. This is an internal parameter (should not be
+   set via environment file), which is fetched from the name attribute of the
+   roles_data.yaml template.
 
  * RoleParameters: Parameter specific to a role on which the service is
-   applied.
+   applied. Using the format "<RoleName>Parameters" in the parameter_defaults
+   of user environment file, parameters can be provided for a specific role.
+   For example, in order to provide a parameter specific to "Compute" role,
+   below is the format::
+
+      parameter_defaults:
+        ComputeParameters:
+          Param1: value
+
 
 Config Settings
 ---------------
@@ -81,6 +95,30 @@ are re-asserted when applying latter ones.
 
    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
 -------------------
 
@@ -117,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.
 
@@ -148,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
 -----------------------------