Merge "Remove unused KeystoneRegion parameter from gnocchi-base"

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

diff --git a/puppet/services/README.rst b/puppet/services/README.rst
index 34cb350..f19b6cc 100644 (file)
--- a/puppet/services/README.rst
+++ b/puppet/services/README.rst
@@ -19,8 +19,21 @@ environment to set per service parameters.
 Config Settings
 ---------------
 
 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
 ----------------
 
 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
 
 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
 
 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:
 
 
    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
 
 
    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
 -----------------------------
 
 Nova Server Metadata Settings
 -----------------------------