Configure ControllerServices via resource chains

This patch wires in a new for Mitaka Heat feature
that allows us to dynamically include a set of nested
stacks representing individual services via a Heat resource chain.
Follow on patches will use this interface to decompose the controller
role into isolated services.

Co-Authored-By: Steve Hardy <shardy@redhat.com>
Depends-On: If510abe260ea7852dfe2d1f7f92b529979483068
Change-Id: I84c97a76159704c2d6c963bc4b26e365764b1366

6 files changed, 112 insertions, 1 deletions

diff --git a/puppet/controller-config-pacemaker.yaml b/puppet/controller-config-pacemaker.yaml
index 21db825a..dfebcf82 100644
--- a/puppet/controller-config-pacemaker.yaml
+++ b/puppet/controller-config-pacemaker.yaml
@@ -8,6 +8,10 @@ parameters:
     default: false
     description: Whether to run config management (e.g. Puppet) in debug mode.
     type: boolean
+  StepConfig:
+     type: string
+     description: Config manifests that will be used to step through the deployment.
+     default: ''
 
 resources:
 
@@ -26,6 +30,7 @@ resources:
         - ''
         - - get_file: manifests/overcloud_controller_pacemaker.pp
           - get_file: manifests/ringbuilder.pp
+          - {get_param: StepConfig}
 
 outputs:
   OS::stack_id:
diff --git a/puppet/controller-config.yaml b/puppet/controller-config.yaml
index f7a6a56d..458aff32 100644
--- a/puppet/controller-config.yaml
+++ b/puppet/controller-config.yaml
@@ -8,6 +8,10 @@ parameters:
     default: false
     description: Whether to run config management (e.g. Puppet) in debug mode.
     type: boolean
+  StepConfig:
+     type: string
+     description: Config manifests that will be used to step through the deployment.
+     default: ''
 
 resources:
 
@@ -26,6 +30,7 @@ resources:
         - ''
         - - get_file: manifests/overcloud_controller.pp
           - get_file: manifests/ringbuilder.pp
+          - {get_param: StepConfig}
 
 outputs:
   OS::stack_id:
diff --git a/puppet/controller-post.yaml b/puppet/controller-post.yaml
index 04f20b61..80b08a06 100644
--- a/puppet/controller-post.yaml
+++ b/puppet/controller-post.yaml
@@ -13,7 +13,10 @@ parameters:
   NodeConfigIdentifiers:
      type: json
      description: Value which changes if the node configuration may need to be re-applied
-
+  StepConfig:
+     type: string
+     description: Config manifests that will be used to step through the deployment.
+     default: ''
 
 resources:
 
@@ -35,6 +38,8 @@ resources:
 
   ControllerPuppetConfig:
     type: OS::TripleO::ControllerConfig
+    properties:
+      StepConfig: {get_param: StepConfig}
 
   # Step through a series of Puppet runs using the same manifest.
   # NOTE: To enable stepping through the deployments via heat hooks,
diff --git a/puppet/controller.yaml b/puppet/controller.yaml
index efdf08bb..d966700f 100644
--- a/puppet/controller.yaml
+++ b/puppet/controller.yaml
@@ -790,6 +790,9 @@ parameters:
     type: json
     description: Optional scheduler hints to pass to nova
     default: {}
+  ServiceConfigSettings:
+    type: json
+    default: {}
 
 resources:
 
@@ -1294,6 +1297,7 @@ resources:
             - heat_config_%{::deploy_config_name}
             - controller_extraconfig
             - extraconfig
+            - service_configs
             - controller
             - database
             - object
@@ -1316,6 +1320,8 @@ resources:
             - neutron_opencontrail_data # Optionally provided by ControllerExtraConfigPre
             - neutron_plumgrid_data # Optionally provided by ControllerExtraConfigPre
           datafiles:
+            service_configs:
+              mapped_data: {get_param: ServiceConfigSettings}
             controller_extraconfig:
               mapped_data: {get_param: ControllerExtraConfig}
             extraconfig:
diff --git a/puppet/services/README.rst b/puppet/services/README.rst
new file mode 100644
index 00000000..38d2ac64
--- /dev/null
+++ b/puppet/services/README.rst
@@ -0,0 +1,50 @@
+========
+services
+========
+
+A TripleO nested stack Heat template that encapsulates generic configuration
+data to configure a specific service. This generally includes everything
+needed to configure the service excluding the local bind ports which
+are still managed in the per-node role templates directly (controller.yaml,
+compute.yaml, etc.). All other (global) service settings go into
+the puppet/service templates.
+
+Input Parameters
+----------------
+
+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.
+
+Config Settings
+---------------
+
+Each service may define a config_settings output variable which returns
+Hiera settings to be configured.
+
+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
+are re-asserted when applying latter ones.
+
+ * config_settings: Custom hiera settings for this service.
+
+ * 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.
+
+   Steps correlate to the following:
+
+   1) Load Balancer configuration
+
+   2) Core Services (Database/Rabbit/NTP/etc.)
+
+   3) Early Openstack Service setup (Ringbuilder, etc.)
+
+   4) General OpenStack Services
+
+   5) Service activation (Pacemaker)
+
+   6) Fencing (Pacemaker)
diff --git a/puppet/services/services.yaml b/puppet/services/services.yaml
new file mode 100644
index 00000000..f9681634
--- /dev/null
+++ b/puppet/services/services.yaml
@@ -0,0 +1,40 @@
+heat_template_version: 2016-04-08
+
+description: >
+  Utility stack to convert an array of services into a set of combined
+  role configs.
+
+parameters:
+  Services:
+    default: []
+    description: |
+        List nested stack service templates.
+    type: comma_delimited_list
+  EndpointMap:
+    default: {}
+    description: Mapping of service endpoint -> protocol. Typically set
+                 via parameter_defaults in the resource registry.
+    type: json
+  MysqlVirtualIPUri:
+    default: ''
+    type: string
+    description: The URI virtual IP for the MySQL service.
+
+resources:
+
+  ServiceChain:
+    type: OS::Heat::ResourceChain
+    properties:
+      resources: {get_param: Services}
+      concurrent: true
+      resource_properties:
+        EndpointMap: {get_param: EndpointMap}
+        MysqlVirtualIPUri: {get_param: MysqlVirtualIPUri}
+
+outputs:
+  config_settings:
+    description: Configuration settings.
+    value: {map_merge: {get_attr: [ServiceChain, role_data, config_settings]}}
+  step_config:
+    description: Step configuration.
+    value: {list_join: ["\n", {get_attr: [ServiceChain, role_data, step_config]}]}