openstack
/
tripleo-heat-templates
Code Issues Proposed changes
tripleo-heat-templates/puppet/services
History
Dan Prince 7588f74919 composable glance services 
Adds new puppet and puppet pacemaker specific services for
Glance API and Glance Registry.

The Pacemaker templates extend the default glance services and
swap in the pacemaker specific puppet-tripleo profile instead.
In the case of pacemaker glance-registry there is no separate
puppet manifest so only the configuration parameters are maintained
there. (Due to the way the pacemaker glance constraints are written
the pacemaker varients of this service can't be split out...)

Depends-On: Ifc388f7058ccfff2818f531bcbc00c7179874bbc
Change-Id: I00a8c916129af43cda225754eb10370289bb4b41
 		2016-04-21 01:03:51 +00:00
..
pacemaker composable glance services 2016-04-21 01:03:51 +00:00
README.rst Configure ControllerServices via resource chains 2016-03-31 16:09:17 -04:00
glance-api.yaml composable glance services 2016-04-21 01:03:51 +00:00
glance-registry.yaml composable glance services 2016-04-21 01:03:51 +00:00
keystone.yaml composable keystone services 2016-04-09 08:36:04 -04:00
services.yaml Configure ControllerServices via resource chains 2016-03-31 16:09:17 -04:00

README.rst

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)