Default snmp to less verbose logging

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

diff --git a/puppet/services/README.rst b/puppet/services/README.rst
index 9c2d8c5..0fb1da6 100644 (file)
--- a/puppet/services/README.rst
+++ b/puppet/services/README.rst
@@ -16,11 +16,43 @@ Each service may define its own input parameters and defaults.
 Operators will use the parameter_defaults section of any Heat
 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.
+
+ * EndpointMap: Mapping of service endpoint -> protocol. Typically set via
+   parameter_defaults in the resource registry.
+
+ * DefaultPasswords: Mapping of service -> default password. Used to help pass
+   top level passwords managed by Heat into services.
+
+ * RoleName: Name of the role on which this service is deployed. A service can
+   be deployed in multiple roles.
+
+ * RoleParameters: Parameter specific to a role on which the service is
+   applied.
+
 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
 ----------------
@@ -87,11 +119,26 @@ 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)
+   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
+
+      The exact order is controlled by the cluster constraints.
+
+   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)