X-Git-Url: https://gerrit.opnfv.org/gerrit/gitweb?a=blobdiff_plain;f=puppet%2Fservices%2FREADME.rst;h=f19b6ccab519b5b4aee3a69b6d425866d9960dd1;hb=82db6ab608b29e455fb2036aeb36537148b97cf9;hp=34cb350bfab65b2a93812e4e5534342f45bc5a27;hpb=61fd803c9a820a335c0e15c73dba19f49270a790;p=apex-tripleo-heat-templates.git

diff --git a/puppet/services/README.rst b/puppet/services/README.rst
index 34cb350b..f19b6cca 100644
--- a/puppet/services/README.rst
+++ b/puppet/services/README.rst
@@ -19,8 +19,21 @@ environment to set per service parameters.
 Config Settings
 ---------------
 
-Each service may define a config_settings output variable which returns
-Hiera settings to be configured.
+Each service may define three ways in which to output variables to configure Hiera
+settings on the nodes.
+
+ * config_settings: the hiera keys will be pushed on all roles of which the service
+   is a part of.
+
+ * global_config_settings: the hiera keys will be distributed to all roles
+
+ * service_config_settings: Takes an extra key to wire in values that are
+   defined for a service that need to be consumed by some other service.
+   For example:
+   service_config_settings:
+     haproxy:
+       foo: bar
+   This will set the hiera key 'foo' on all roles where haproxy is included.
 
 Deployment Steps
 ----------------
@@ -57,10 +70,14 @@ 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. Note that each step is performed in batches,
-then we move on to the next step which is also performed in batches (we don't
-perform all steps on one node, then move on to the next one which means you
-can sequence rolling upgrades of dependent services via the step value).
+step, "step2" for the second, etc (currently only two steps are supported, but
+more may be added when required as additional services get converted to batched
+upgrades).
+
+Note that each step is performed in batches, then we move on to the next step
+which is also performed in batches (we don't perform all steps on one node,
+then move on to the next one which means you can sequence rolling upgrades of
+dependent services via the step value).
 
 The tasks performed at each step is service specific, but note that all batch
 upgrade steps are performed before the `upgrade_tasks` described below.  This
@@ -83,19 +100,34 @@ step, "step2" for the second, etc.
 
    Steps/tages correlate to the following:
 
-   1) Quiesce the control-plane, e.g disable LoadBalancer, stop pacemaker cluster
+   1) Stop all control-plane services.
+
+   2) Quiesce the control-plane, e.g disable LoadBalancer, stop
+      pacemaker cluster: this will stop the following resource:
+      - ocata:
+        - galera
+        - rabbit
+        - redis
+        - haproxy
+        - vips
+        - cinder-volumes
+        - cinder-backup
+        - manilla-share
+        - rbd-mirror
 
-   2) Stop all control-plane services, ready for upgrade
+      The exact order is controlled by the cluster constraints.
 
-   3) Perform a package update, (either specific packages or the whole system)
+   3) Perform a package update and install new packages: A general
+      upgrade is done, and only new package should go into service
+      ansible tasks.
 
    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)
+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.
 
 Nova Server Metadata Settings
 -----------------------------