Update t-h-t walkthrough documentation

This updates the steps to reference the dynamic roles we now have.
Instead of the hardcoded ones.

It also documents the service_config_settings.

Change-Id: I83526fd46b5eb53a70436f2303550829ec096396

doc/source/developer/tht_walkthrough/changes-tht.rst

@@ -93,39 +93,49 @@ configure our resources. In the example case the created resource
 (puppet/services/time/ntp.yaml).
 
 
-Step 3 - overcloud.yaml initial changes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Step 3 - roles_data.yaml initial changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Mandatory services should be added to the ControllerServices parameter default value,
-which defines all the services enabled by default in the controller(s).
+The default roles are defined here. They are then iterated and the respective
+values of each section are rendered into the overcloud.j2.yaml.
 
-From ``overcloud.yaml`` in the parameters section find:
-::
+Mandatory services should be added to the roles' ServicesDefault value,
+which defines all the services enabled by default in the role(s).
 
-  ControllerServices:
-    default:
-      - OS::TripleO::Services::Keystone
-      - OS::TripleO::Services::GlanceApi
-      - OS::TripleO::Services::GlanceRegistry
-      - OS::TripleO::Services::Ntp              ---> New service deployed in the controller overcloud
-    description: A list of service resources (configured in the Heat
-                 resource_registry) which represent nested stacks
-                 for each service that should get installed on the Controllers.
-    type: comma_delimited_list
+From ``roles_data.yaml`` find::
+
+    - name: Controller
+      CountDefault: 1
+      ServicesDefault:
+        - OS::TripleO::Services::CACerts
+        - OS::TripleO::Services::CertmongerUser
+        - OS::TripleO::Services::CephMds
+        - OS::TripleO::Services::Keystone
+        - OS::TripleO::Services::GlanceApi
+        - OS::TripleO::Services::GlanceRegistry
+        ...
+        - OS::TripleO::Services::Ntp              ---> New service deployed in the controller overcloud
 
 
 Update this section with your new service to be deployed to the controllers in
 the overcloud.
 
-The parameter ControllerServices will be used by the ControllerServiceChain
-resource as follows:
-::
+These values will be used by the controller roles' ServiceChain resource as
+follows::
 
-  ControllerServiceChain:
-    type: OS::TripleO::Services
-    properties:
-      Services: {get_param: ControllerServices}
-      EndpointMap: {get_attr: [EndpointMap, endpoint_map]}
+    {% for role in roles %}
+      # Resources generated for {{role.name}} Role
+      {{role.name}}ServiceChain:
+        type: OS::TripleO::Services
+        properties:
+          Services:
+            get_param: {{role.name}}Services
+          ServiceNetMap: {get_attr: [ServiceNetMap, service_net_map]}
+          EndpointMap: {get_attr: [EndpointMap, endpoint_map]}
+          DefaultPasswords: {get_attr: [DefaultPasswords, passwords]}
+
+    ...
+    {% endfor %}
 
 THT changes for all the different roles are covered in:
 
@@ -139,9 +149,10 @@ THT changes for all the different roles are covered in:
 
 .. note::
 
-  In the case of the controller services, they are defined as part of the ControllerServiceChain
-  resource. If it is needed to add optional services, they need to be appended to the current
-  services list defined by the default value of the ControllerServices parameter.
+  In the case of the controller services, they are defined as part of the
+  roles' ServiceChain resource. If it is needed to add optional services, they
+  need to be appended to the current services list defined by the default
+  value of the role's ServicesDefault parameter.
 
 
 Step 4 - Create the services yaml files
@@ -199,3 +210,23 @@ configured.
   duplicated parameters among different deployment environments
   (i.e. using pacemaker). To do this see
   section :ref:`duplicated-parameters`.
+
+  If your service has configuration that affects another service and should
+  only be run on nodes (roles) that contain that service, you can use
+  "service_config_settings". You then have to specify the hieradata inside this
+  section by using the name of the service as the key. So, if you want to
+  output hieradata related to your service, on nodes that deploy keystone, you
+  would do this::
+
+    role_data:
+      ...
+    step_config:
+      ...
+    ...
+    service_config_settings:
+      keystone:
+        # Here goes the hieradata
+
+  This is useful for things such as creating the keystone endpoints for your
+  service, since one usually wants these commands to only be run on the
+  keystone node.

doc/source/developer/tht_walkthrough/introduction.rst

@@ -19,15 +19,8 @@ manifests will be re-defined in the puppet-tripleo repository, and adapted to
 the `composable services architecture`_.
 
 The use case for this example uses NTP as a service installed by default among
-the OpenStack deployment. In this particular case, NTP is installed and
-configured based on the code from puppet manifests:
-
-``puppet/manifests/overcloud_cephstorage.pp``,
-``puppet/manifests/overcloud_volume.pp``,
-``puppet/manifests/overcloud_object.pp``,
-``puppet/manifests/overcloud_compute.pp``,
-``puppet/manifests/overcloud_controller.pp`` and
-``puppet/manifests/overcloud_controller_pacemaker.pp``
+the OpenStack deployment. So the profile needs to be added to all the roles in
+roles_data.yaml.
 
 Which means that NTP will be installed everywhere in the overcloud, so the
 tutorial will describe the process of refactoring the code from those files
@@ -71,4 +64,4 @@ the proposed patch (https://review.openstack.org/#/c/259568) controller
 services will be wired to a new Heat feature that allows it to dynamically include
 a set of nested stacks representing individual services via a Heat resource
 chain. The current example will use this interface to decompose the controller
-role into isolated services.
+role into isolated services.