1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
========
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:
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)
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:
1) Quiesce the control-plane, e.g disable LoadBalancer, stop pacemaker cluster
2) Stop all control-plane services, ready for upgrade
3) Perform a package update, (either specific packages or the whole system)
4) Start services needed for migration tasks (e.g DB)
5) Perform any migration tasks, e.g DB sync commands
6) Start control-plane services
7) 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.
|
