2f0121bee849a8b717399b03aa90aec6b968cb66
[octopus.git] / scenarios / templates / sdf-template.yaml
1 ---
2 ##############################################################################
3 # Copyright (c) 2017 Huawei and others.
4 # ulrich.kleber@huawei.com
5 # All rights reserved. This program and the accompanying materials
6 # are made available under the terms of the Apache License, Version 2.0
7 # which accompanies this distribution, and is available at
8 # http://www.apache.org/licenses/LICENSE-2.0
9 ##############################################################################
10
11 ##############################################################################
12 # Description:
13 # This is the template for all scenario descriptor files (sdf)
14 # Every OPNFV scenario is described in an sdf.yaml located in the
15 # scenarios folder in Octopus repo.
16 # The sdf is provided by the scenario owner and consumed by CI, deployment
17 # tools and test frameworks.
18 #
19 # Main sections:
20 #
21 # metadata (owner, history, description)
22 # list of components (names, versions, submodules)
23 # deployment options (HA/NOHA, hardware&virtualization, installers,
24 #                     configurations)
25 # other prerequisites (e.g. memory requirement more than pharos spec)
26 #
27 # More details can be found in the scenario lifecycle document.
28 ##############################################################################
29
30 ##############################################################################
31 # scenario meta-data    # Metadata describing this sdf.yaml file and the
32 #                         scenario history and purpose.
33 scenario-metadata:
34   name: SDF-Template            # mandatory
35   # This is a free name.
36   # For Generic scenarios, the main distiguishing components can be included in
37   # the name. The name will be approved by TSC when the generic scenario is
38   # established. Examples: OS-ODL-OVSNSH, OS-ONOS, OS-ODL-FDIO,
39   # OS-OVSBasic, OS-FDIOBasic, ...
40   # For specific scenarios, the name should characterize the main
41   # feature that is implemented here. Examples: Bgpvpn, Netvirt-gbp-vpp,
42   # Dpdk-bar, Onos-sfc, ...
43   # Final rules for naming will be set by the lifecycle document and TSC
44   # approval.
45   title: "SDF template"         # mandatory
46   # descriptive text title maximum 10-12 words telling the main purpose
47   generic-scenario: false       # optional, default = false
48   version: 1.0.6                # mandatory
49   # version number of the sdf, three digits separated with dots
50   creation-date: 2017-05-09    # mandatory
51   # creation of this sdf file version
52   # Please add a clear description of the purpose of the scenario, including
53   # the main benefits and major features (mandatory).
54   # If applicable, the parent scenario should be mentioned.
55   opnfv-release: euphrates      # mandatory
56   # the first opnfv release, the scenario was introduced
57   opnfv-version:
58     - begins: 5.1.0             # mandatory
59     # the first opnfv version, the scenario was released with
60     - ends: 7.3.0               # optional
61     # the last opnfv version that supports this scenario. Typically the features
62     # of the scenario should have been merged to generic scenarios then
63   owner: Ulrich Kleber, ulrich.kleber@huawei.com  # mandatory
64 # author of this file and thus owner of the scenario
65 # Add additional contact persons e.g. from installers or major components
66
67 ##############################################################################
68
69 ##############################################################################
70 # components
71 # All components/submodules/features in the list shall be deployed
72 components:                     # mandatory section
73   # In this section all components are listed together with their version.
74   # For some components in addtion submodules or optional features can
75   # be listed.
76   - sdn-controller:             # optional, default = no sdn controller
77     # most important categories here are: sdn-controller, cloud-controller,
78     # storage, virtual-switching, dataplane, nfvo, vnfm, but new categories
79     # can be introduced any time.
80     # Every component to be deployed should be listed with such a section.
81     # If the component has submodules or optional features, they also need
82     # to be listed.
83     type: opendaylight        # mandatory, other options e.g.onos, ocl, ovn
84     release: boron            # either release or version or both must be given
85     # upstream version, human readable release name
86     version: 5.0.1
87     # exact semantic version including patch level
88     # Normally installers will not be able to pick exact semantic versions, but
89     # if the scenario requires specific versions, this can be checked offline.
90     # Following syntax variants can be allowed as well:
91     #     version: 5.*.*
92     #     version: ">5.0.3"
93     features:                 # optional
94       # additional feature configurations as recognized by the installers.
95       - odl_l2
96       - sfc
97       - bgpvpn
98
99   - storage:                 # optional
100       type: ceph
101
102   - cloud-controller:        # seems to me mandatory
103       type: openstack        # other option could be kubernetes
104       release: ocata         # either release or version or both must be given
105       version: 15.0.0
106       # An OPNFV version can go only with one openstack version.
107       # Typically installers cannot pick different openstack version,
108       # but this can be checked offline.
109       modules:                  # optional
110         # Installers have a basic set of modules that are deployed by
111         # default. Those can be listed optional. Scenario owners can
112         # list additional optional modules with their name as on
113         # https://wiki.openstack.org/software/project-navigator, but
114         # with lower case and dashes, Examples: tacker, kuryr, horizon,
115         # vitrage, chef-openstack, openstack-charms, etc.
116         # Independent of big tent, modules can be used if installers
117         # support their deployment.
118         - nova
119         - cinder
120         - horizon
121         - glance
122         - heat
123         - neutron:
124             features:   # In some cases features need to be listed specifically
125               - bgpvpn  # listing service plugins as neutron features makes
126         # it easier for installers, they don't need to take this
127         # information from the features field in the sdn-controller.
128         - aodh
129         - tacker
130         - congress
131
132   - virtual-switching:      # optional
133       # showing with this example how to include a separate
134       # configuration file for this
135       type: ovs
136       release: xx           # either release or version or both must be given
137       version: 2.6.1
138       features:             # optional
139         - vsperf:
140             file: scenarios/ovs-config.yaml
141 # this file then should contain additional configurations to use like
142 # hugepage-size, iommu, ...
143 # it will be treated like a C #include statement.
144 # Please note, the template cannot show all possible options here. There will be
145 # more in an additional document.
146 # Correct usage of the keywords/options will be enforced by a schema.
147 # Also note that some component related deployment information will be
148 # in the options section.
149 ##############################################################################
150
151 ##############################################################################
152 # deployment options
153 # In this section, CI will select one of the listed options and needs to pass
154 # the information to the installer via a parameter or environment.
155 deployment-options:             # mandatory
156   deployment-types:             # at least one section must be provided
157     - baremetal:
158       architecture: x86_64
159       features:                 # optional
160         - dpdk
161         - other
162     # $$$$ Discussion open whether we need features here after adding
163     # them in roles section
164     - baremetal:
165       architecture: arm64
166     - virtual:
167       # $$$$ Discussion open whether this is necessary here.
168       architecture: x86_64
169       features:
170         - xyz
171
172   # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
173   # Discussion open how to specify the distribution of components on nodes.
174   # Three proposals:
175   # 1. specify availability options ha, noha by placing functions on nodes
176   # 2. specify roles like compute-node, controller-node and only their number,
177   #    thus avoid coupling with hostnames and more flexible mapping to different
178   #    sizes of PODs.
179   # 3. Leave it to installers and just specify whether ha or noha are supported
180   # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
181   # Proposal 1:
182   availability:                 # mandatory
183     # here the configuration for a HA and NONHA deployment is described.
184     # It is similar to what compass has in host section (minus the POD info),
185     # or fuel in the dea-override-config or dha-override-config
186     - ha:                       # minimum one of ha or noha must be specified
187         nodes:                  # a description like this is mandatory
188           - name: [host1, host2, host3]  # avoid to list the same multiple times
189             roles:
190               # took this from compass. Is it sufficient?
191               - openstack-controller
192               - odl
193               - ceph-adm
194               - ceph-mon
195           - name: [host4, host 5]
196             roles:
197               - openstack-compute
198               - ceph-osd
199     - noha:
200         hosts:
201           - name: host1
202             roles:
203               - openstack-controller
204               - odl
205               - ceph-adm
206               - ceph-mon
207           - name: host2
208             roles:
209               - openstack-compute
210               - ceph-osd
211           - name: host3
212             roles:
213               - openstack-compute
214               - ceph-osd
215
216   # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
217   # Proposal 2:
218   roles:              # mandatory
219     - controller-node:
220         components:   # list all components that are deployed here.
221           - openstack: control
222           - opendaylight
223           - ceph: [ceph-adm, ceph-mon]
224           - ovs
225     - compute-node:
226         components:
227           - openstack: compute
228           - ceph: ceph-osd
229           - ovs
230         hardware-features:
231           - dpdk
232     - jump-host:      # some scenarios, e.g. MANO might deploy components here
233
234   role-distribution:  # mandatory
235     - ha:
236         controller-node: 3
237         compute-node: 2
238         jump-host: 1
239     - noha:
240         controller-node: 1
241         compute-node: 4
242         jump-host: 1
243
244   # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
245   # Proposal 3:
246   # no specification of nodes/roles here. ha, noha are defined by installers
247
248   deployment-tools:             # mandatory
249     # In the section for each deployment tool, the combinations of the
250     # first three options have to be listed. CI can pick any of the sections.
251     - fuel:                     # at least one section
252         cpu: intel             # optional, default = intel
253         pod: baremetal
254         availability: ha
255     - fuel:
256         cpu: intel
257         pod: virtual
258         availability: ha
259     - fuel:
260         cpu: intel
261         pod: virtual
262         availability: noha
263     - fuel:
264         cpu: arm
265         pod: baremetal
266         availability: noha
267     - compass:
268         cpu: intel
269         pod: baremetal
270         availability: ha
271     - joid:
272         cpu: intel
273         pod: baremetal
274         availability: ha
275
276 ##############################################################################
277
278 ##############################################################################
279 # Prerequisites
280 # This section will list additional prerequisites. Currently there is only
281 # one case where a scenario has additional prerequisites to the Pharos spec.
282 # Open-O deployment requires 64GB of memory while Pharos spec requires 32GB.
283 # In general it should be preferred to issue such requirements to pharos
284 # using the pharos change request process, but in some cases in might be
285 # better to specify additional prerequisites.
286 # Another use case for these prerequisites will be usage of specilized
287 # hardware, e.g. for acceleration. This needs further study.
288
289 prerequisites:                  # The section can be empty or omitted.
290   - controller-node:            # Prerequisites might be different
291       RAM: 128GB                # optional, just to give examples
292       cpu: dual-core
293       features:                 # optional, see example below
294   - compute-node:
295       RAM: 128GB
296       cpu: dual-core
297       features:
298         - dpdk
299   - jumphost:                   # Prerequisites can be given also for jumphost
300       RAM: 128GB
301       cpu: dual-core
302
303 ##############################################################################

© 2018 OPNFV. Copyright © The Linux Foundation ®. All Rights Reserved.
The Linux Foundation has registered trademarks and uses trademarks.
For a list of trademarks of The Linux Foundation, please see our Trademark Usage page.
Linux is a registered trademark of Linus Torvalds.
Privacy Policy and Terms of Use