Introduce THT for networking-fujitsu. networking-fujitsu is a neutron ML2 plugin
which enables FUJITSU C-Fabric switch in OpenStack environment. This templates
deploy overcloud with C-Fabric switch.
Change-Id: Iee75a1a30552d8dc9f55f52d10b0dc2b623992ef
Implements: blueprint integration-networking-fujitsu
Depends-On: I37a502b43eb7d91bfe20625248ed117eae3ca535
Depends-On: I5eb2c2a9c50b5991d62f4b6d74b83351c86b02de
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.
4183f665f6