Juan Antonio Osorio Robles d2da59065d Add hook to generate metadata from service profiles

This enables the deployer to dynamically add nova metadata to the
servers based on the output of service profiles that implement the
metadata_settings key in the role_data output for the profiles.

One can set an implementation via the OS::TripleO::ServerMetadataHook
resource, which currently is set as OS::Heat::None. So, because of
the default implementation, if left untouched it actually does
nothing.

Currently, besides the list, which is metadata_settings, this hook also
takes the name of the node that it's setting the metadata for.

This is useful for nova vendordata plugins that can parse said metadata.

Change-Id: I8a937f711f0b90156fbb6c4632760435ef846474

2016-12-22 10:06:17 +00:00

3.0 KiB

Raw Blame History

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.

Deployment 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:

Load Balancer configuration

Core Services (Database/Rabbit/NTP/etc.)

Early Openstack Service setup (Ringbuilder, etc.)

General OpenStack Services

Service activation (Pacemaker)

Upgrade Steps

Each service template may optionally define a upgrade_tasks key, which is a list of ansible tasks to be performed during the upgrade process.

Similar to the step_config, we allow a series of steps for the per-service upgrade sequence, defined as ansible tasks with a tag e.g "step1" for the first step, "step2" for the second, etc.

Steps/tages correlate to the following:

Quiesce the control-plane, e.g disable LoadBalancer, stop pacemaker cluster

Stop all control-plane services, ready for upgrade

Perform a package update, (either specific packages or the whole system)

Start services needed for migration tasks (e.g DB)

Perform any migration tasks, e.g DB sync commands

Start control-plane services

Any additional online migration tasks (e.g data migrations)

Nova Server Metadata Settings

One can use the hook of type OS::TripleO::ServiceServerMetadataHook to pass entries to the nova instances' metadata. It is, however, disabled by default. In order to overwrite it one needs to define it in the resource registry. An implementation of this hook needs to conform to the following:

It needs to define an input called RoleData of json type. This gets as input the contents of the role_data for each role's ServiceChain.
This needs to define an output called metadata which will be given to the Nova Server resource as the instance's metadata.

3.0 KiB Raw Blame History