X-Git-Url: https://gerrit.opnfv.org/gerrit/gitweb?a=blobdiff_plain;f=puppet%2Fservices%2FREADME.rst;h=6e4e9c1d66f16e370e582eaa61896bf6866905c9;hb=38ac78ba5d302b9d99009336d80a7f19c938826b;hp=38d2ac64b92b9bbd1cdaee69687210e3ebfc91d3;hpb=172ded7a402e1ac28cc9601ab9faf815df98742e;p=apex-tripleo-heat-templates.git

diff --git a/puppet/services/README.rst b/puppet/services/README.rst
index 38d2ac64..6e4e9c1d 100644
--- a/puppet/services/README.rst
+++ b/puppet/services/README.rst
@@ -22,8 +22,8 @@ Config Settings
 Each service may define a config_settings output variable which returns
 Hiera settings to be configured.
 
-Steps
------
+Deployment Steps
+----------------
 
 Each service may define an output variable which returns a puppet manifest
 snippet that will run at each of the following steps. Earlier manifests
@@ -31,6 +31,8 @@ are re-asserted when applying latter ones.
 
  * config_settings: Custom hiera settings for this service.
 
+ * global_config_settings: Additional hiera settings distributed to all roles.
+
  * step_config: A puppet manifest that is used to step through the deployment
    sequence. Each sequence is given a "step" (via hiera('step') that provides
    information for when puppet classes should activate themselves.
@@ -47,4 +49,42 @@ are re-asserted when applying latter ones.
 
    5) Service activation (Pacemaker)
 
-   6) Fencing (Pacemaker)
+Upgrade Steps
+-------------
+
+Each service template may optionally define a `upgrade_tasks` key, which is a
+list of ansible tasks to be performed during the upgrade process.
+
+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:
+
+   1) Quiesce the control-plane, e.g disable LoadBalancer, stop pacemaker cluster
+
+   2) Stop all control-plane services, ready for upgrade
+
+   3) Perform a package update, (either specific packages or the whole system)
+
+   4) Start services needed for migration tasks (e.g DB)
+
+   5) Perform any migration tasks, e.g DB sync commands
+
+   6) Start control-plane services
+
+   7) Any additional online migration tasks (e.g data migrations)
+
+Nova Server Metadata Settings
+-----------------------------
+
+One can use the hook of type `OS::TripleO::ServiceServerMetadataHook` to pass
+entries to the nova instances' metadata. It is, however, disabled by default.
+In order to overwrite it one needs to define it in the resource registry. An
+implementation of this hook needs to conform to the following:
+
+* It needs to define an input called `RoleData` of json type. This gets as
+  input the contents of the `role_data` for each role's ServiceChain.
+
+* This needs to define an output called `metadata` which will be given to the
+  Nova Server resource as the instance's metadata.