Files
tripleo-heat-templates/puppet/services
Dan Prince 933f1afefd Stop using puppet to configure VIPs in /etc/hosts
This patch drops use of the vip-hosts.yaml service which can
cause issues during deployment because puppet 'hosts' resources
overwrite the data in /etc/hosts. The only reason things seem to work
at all at the moment is because our hosts element in t-i-e runs
on each os-refresh-config iteration and re-adds the dropped hosts
entries.

To work around the issue we add a conditional which selectively
adds the extra hosts entries only if the AddVipsToEtcHosts is set
to true.

Closes-bug: 1645123

Change-Id: Ic6aaeb249a127df83894f32a704219683a6382b2
2016-11-27 13:20:33 -05:00
..
2016-11-11 11:16:02 +01:00
2016-09-27 16:11:10 +02:00
2016-09-17 01:31:12 +00:00
2016-10-21 16:22:40 +02:00
2016-11-04 11:12:43 +01:00
2016-11-17 14:22:53 +00:00
2016-10-21 08:07:08 -04:00
2016-10-21 08:07:08 -04:00
2016-09-17 01:31:12 +00:00
2016-09-01 16:06:38 -04:00
2016-09-17 01:31:12 +00:00
2016-09-17 01:31:12 +00:00
2016-10-26 10:09:41 +02:00

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.

  • global_config_settings: Additional hiera settings distributed to all roles.

  • 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)

Note: Not all roles currently support all steps:

  • ObjectStorage role only supports steps 2, 3 and 4