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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. (c) 2017 OPNFV Ulrich Kleber (Huawei)
Scenario Descriptor Files
----------------------------
What are Scenario Descriptor Files?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Every scenario is described in its own descriptor file.
The scenario descriptor file will be used by several parties:
* Installer tools will read from it the list of components to be installed
and the configuration (e.g. deployment options and necessary details) to use.
* The dynamic CI process will read from it the prerequisites of the scenario
to select the resource that has the needed capabilities for the deployment.
It will also select the installer
from the list of supported installers and the other deployment options as
supported in their combination.
The dynamic CI process will provide the installers with the deployment option
to use for a particular deployment.
* The scenario owner needs to provide the descriptor file.
When compiling it the scenario owner typically needs to work together with
the installers, so the installers will support the required components and
options.
* The testing framework can read from the scenario descriptor file necessary
information to know which features can be tested on the scenario.
* The scenario descriptor file will also contain some maintenance information
Structure of the file
^^^^^^^^^^^^^^^^^^^^^^^^^^
The scenario descriptor file is a yaml file. The syntax will allow to specify
additional descriptor files, to make it better readable or structure common
configurations across multiple scenarios.
The file has following main sections:
* metadata (owner, history, description)
* list of components (names, versions, submodules)
* deployment options (HA/NOHA, hardware&virtualization, installers, including
possible combinations and necessary details)
* other prerequisites (e.g. memory requirement more than pharos spec)
* list of features to be tested
More information to be provided in next version of this document. The file will
be defined based on the installer-specific files for scenario specification
used by the 4 installers in Danube release. Thus it will be made sure that the
information needed by the installers will be covered.
All scenario files will be stored in a central repo, e.g. Octopus. There will
also be a commented template to help create scenario descriptor files.
Metadata
^^^^^^^^^^^^^^^^^^^^^^^^^^
In Danube timeframe only Fuel installer has some metadata in the descriptor file.
The new template contains:
* Unique name
This is a free name, there is a recommendation to take fish for names, matching
OPNFV release naming with rivers.
* A free text title
This should be a short descriptive text telling the main purpose
* A version number for the descriptor file
Three digits, separated with dots, as used by Fuel in Danube
* Creation date
* Comment
The file should contain a clear description of the purpose of the scenario,
including the main benefits and major features.
If applicable, the parent scenario should be mentioned.
* First OPNFV version to use the scenario
* Author/Owner
* A list of additional contact persons, e.g. from installers or major components
Components
^^^^^^^^^^^^^^^^
In this section all components are listed together with their version.
For some components in addtion submodules can be listed.
More details will be added.
Deployment options
^^^^^^^^^^^^^^^^^^^^^^^^^^
This section will list the supported deployment options. In each category at least
one option must be supported.
* hardware (cpu) types (intel or ARM)
* Virtualization (bare-metal or vPOD)
* availability (HA or NOHA)
This subsection needs to specify also what does an HA deployment need, e.g.:
::
availability:
- type: HA
nodes:
- name: host1
roles:
- openstack-controller
- odl
- ceph-adm
- ceph-mon
- name: host2
roles:
- openstack-controller
- odl
- ceph-adm
- ceph-mon
- name: host3
roles:
- openstack-controller
- odl
- ceph-adm
- ceph-mon
- name: host4
- openstack-compute
- ceph-osd
- name: host5
- openstack-compute
- ceph-osd
- type: NOHA
hosts:
- name: host1
roles:
- openstack-controller
- odl
- ceph-adm
- ceph-mon
- name: host2
- openstack-compute
- ceph-osd
- name: host3
- openstack-compute
- ceph-osd
* deployment tool (apex, compass, fuel, daisy, joid)
In the section for each deployment tool, the combinations of the first three
options have to be listed, e.g.:
::
deployment-tools:
- type: fuel
cpu: intel
pod: baremetal
availability: HA
- type: fuel
cpu: intel
pod: virtual
availability: HA
- type: fuel
cpu: intel
pod: virtual
availability: NOHA
Please note that this allows easy definition of other availability options
including scaling and redundant configuration of SDN controllers.
Prerequisites
^^^^^^^^^^^^^^^^^^^^^^^^^^
This section will list additional prerequisites. Currently there is only
one case where a scenario has additional prerequisites to the Pharos spec.
E.g. a component could requires more RAM on the nodes than defined in
Pharos spec.
In general it should be preferred to issue such requirements to pharos
using the pharos change request process, but in some cases in might be
better to specify additional prerequisites.
Another use case for these prerequisites will be usage of specilized
hardware, e.g. for acceleration. This needs further study.
The section can be empty or omitted.
Testcases
^^^^^^^^^^^^^^^^
This section will provide information for functest and yardstick to decide
on the proper test cases for the scenario.
More details will be added.
Shared settings
^^^^^^^^^^^^^^^^
This descriptor file might get quite long and complex. Also some of the settings
will be shared between several scenarios, e.g. a long OpenStack module list.
Therefore it shall be possible to reference another file like a macro.
In that case all the file content is included in that place, e.g.:
::
availability:
- type: HA
file: odl-ha-configuration.yaml
|
