openstack
/
tripleo-heat-templates
Code Issues Proposed changes
tripleo-heat-templates/docker/services
History
Steven Hardy 3c6ec654b4 Bump template version for all templates to "ocata" 
Heat now supports release name aliases, so we can replace
the inconsistent mix of date related versions with one consistent
version that aligns with the supported version of heat for this
t-h-t branch.

This should also help new users who sometimes copy/paste old templates
and discover intrinsic functions in the t-h-t docs don't work because
their template version is too old.

Change-Id: Ib415e7290fea27447460baa280291492df197e54
 		2016-12-23 11:43:39 +00:00
..
README.rst Containerized Services for Composable Roles 2016-11-22 11:42:49 +01:00
neutron-ovs-agent.yaml Bump template version for all templates to "ocata" 2016-12-23 11:43:39 +00:00
nova-compute.yaml Bump template version for all templates to "ocata" 2016-12-23 11:43:39 +00:00
nova-libvirt.yaml Bump template version for all templates to "ocata" 2016-12-23 11:43:39 +00:00
services.yaml Bump template version for all templates to "ocata" 2016-12-23 11:43:39 +00: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. These are used to generate configs.
  • 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.
  • docker_compose:
  • container_name:
  • volumes:

Steps correlate to the following:

  1. Service configuration generation with puppet.
  2. Early Openstack Service setup (database init?)
  3. Early containerized networking services startup (OVS)
  4. Network configuration
  5. General OpenStack Services
  6. Service activation (Pacemaker)
  7. Fencing (Pacemaker)