1 ##############################################################################
2 # Copyright (c) 2017 Huawei and others.
3 # ulrich.kleber@huawei.com
4 # All rights reserved. This program and the accompanying materials
5 # are made available under the terms of the Apache License, Version 2.0
6 # which accompanies this distribution, and is available at
7 # http://www.apache.org/licenses/LICENSE-2.0
8 ##############################################################################
10 ##############################################################################
12 # This is the template for all scenario descriptor files (sdf)
13 # Every OPNFV scenario is described in an sdf.yaml located in the
14 # scenarios folder in Octopus repo.
15 # The sdf is provided by the scenario owner and consumed by CI, deployment
16 # tools and test frameworks.
20 # metadata (owner, history, description)
21 # list of components (names, versions, submodules)
22 # deployment options (HA/NOHA, hardware&virtualization, installers, configurations)
23 # other prerequisites (e.g. memory requirement more than pharos spec)
25 # More details can be found in the scenario lifecycle document.
26 ##############################################################################
28 ##############################################################################
29 # scenario meta-data # Metadata describing this sdf.yaml file and the scenario
30 # history and purpose.
32 name: SDF-Template # mandatory
33 # This is a free name.
34 # For Generic scenarios, the main distiguishing components can be included in
35 # the name. The name will be approved by TSC when the generic scenario is
36 # established. Examples: OS-ODL-OVSNSH, OS-ONOS, OS-ODL-FDIO,
37 # OS-OVSBasic, OS-FDIOBasic, ...
38 # For specific scenarios, the name should characterize the main
39 # feature that is implemented here. Examples: Bgpvpn, Netvirt-gbp-vpp,
40 # Dpdk-bar, Onos-sfc, ...
41 # Final rules for naming will be set by the lifecycle document and TSC approval.
42 title: "SDF template" # mandatory
43 # descriptive text title maximum 10-12 words telling the main purpose
44 generic-scenario: false # optional, default = false
45 version: 1.0.6 # mandatory
46 # version number of the sdf, three digits separated with dots
47 creation-date: 2017-05-09 # mandatory
48 # creation of this sdf file version
49 # Please add a clear description of the purpose of the scenario, including
50 # the main benefits and major features (mandatory).
51 # If applicable, the parent scenario should be mentioned.
52 opnfv-release: euphrates # mandatory
53 # the first opnfv release, the scenario was introduced
55 - begins: 5.1.0 # mandatory
56 # the first opnfv version, the scenario was released with
57 - ends: 7.3.0 # optional
58 # the last opnfv version that supports this scenario. Typically the features
59 # of the scenario should have been merged to generic scenarios then
60 owner: Ulrich Kleber, ulrich.kleber@huawei.com # mandatory
61 # author of this file and thus owner of the scenario
62 # Add additional contact persons e.g. from installers or major components
64 ##############################################################################
66 ##############################################################################
68 # All components/submodules/features in the list shall be deployed
69 components: # mandatory section
70 # In this section all components are listed together with their version.
71 # For some components in addtion submodules or optional features can be listed.
72 - sdn-controller: # optional, default = no sdn controller
73 # most important categories here are: sdn-controller, cloud-controller,
74 # storage, virtual-switching, dataplane, nfvo, vnfm, but new categories
75 # can be introduced any time.
76 # Every component to be deployed should be listed with such a section.
77 # If the component has submodules or optional features, they also need
79 type: opendaylight # mandatory, other options e.g.onos, ocl, ovn
80 release: boron # either release or version or both must be given
81 # upstream version, human readable release name
83 # exact semantic version including patch level
84 # Normally installers will not be able to pick exact semantic versions, but
85 # if the scenario requires specific versions, this can be checked offline.
86 # Following syntax variants can be allowed as well:
90 # additional feature configurations as recognized by the installers.
98 - cloud-controller: # seems to me mandatory
99 type: openstack # other option could be kubernetes
100 release: ocata # either release or version or both must be given
102 # An OPNFV version can go only with one openstack version. Typically installers
103 # cannot pick different openstack version, but this can be checked offline.
105 # Installers have a basic set of modules that are deployed by default. Those
106 # can be listed optional. Scenario owners can list additional optional modules
107 # with their name as on https://wiki.openstack.org/software/project-navigator,
108 # but with lower case and dashes, Examples: tacker, kuryr, horizon, vitrage,
109 # chef-openstack, openstack-charms, etc.
110 # Independent of big tent, modules can be used if installers support their deployment.
117 features: # In some cases features need to be listed specifically
118 - bgpvpn # listing service plugins as neutron features makes
119 # it easier for installers, they don't need to take this information from the features
120 # field in the sdn-controller.
125 - virtual-switching: # optional
126 # showing with this example how to include a separate configuration file for this
128 release: xx # either release or version or both must be given
132 file: scenarios/ovs-config.yaml
133 # this file then should contain additional configurations to use like
134 # hugepage-size, iommu, ...
135 # it will be treated like a C #include statement.
136 # Please note, the template cannot show all possible options here. There will be
137 # more in an additional document.
138 # Correct usage of the keywords/options will be enforced by a schema.
139 # Also note that some component related deployment information will be in the options
141 ##############################################################################
143 ##############################################################################
145 # In this section, CI will select one of the listed options and needs to pass
146 # the information to the installer via a parameter or environment.
147 deployment-options: # mandatory
148 deployment-types: # at least one section must be provided
154 #$$$$ Discussion open whether we need features here after adding them in roles section
158 #$$$$ Discussion open whether this is necessary here.
163 #$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
164 # Discussion open how to specify the distribution of components on nodes.
166 # 1. specify availability options ha, noha by placing functions on nodes
167 # 2. specify roles like compute-node, controller-node and only their number,
168 # thus avoid coupling with hostnames and more flexible mapping to different
170 # 3. Leave it to installers and just specify whether ha or noha are supported
172 #$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
174 availability: # mandatory
175 # here the configuration for a HA and NONHA deployment is described.
176 # It is similar to what compass has in host section (minus the POD info),
177 # or fuel in the dea-override-config or dha-override-config
178 - ha: # minimum one of ha or noha must be specified
179 nodes: # a description like this is mandatory
180 - name: [host1, host2, host3] # avoid to list the same multiple times
182 - openstack-controller # took this from compass. Is it sufficient?
186 - name: [host4, host 5]
194 - openstack-controller
207 #$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
211 components: # list all components that are deployed here.
214 - ceph: [ceph-adm, ceph-mon]
223 - jump-host: # some scenarios, e.g. MANO might deploy components here
225 role-distribution: # mandatory
235 #$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
237 # no specification of nodes/roles here. ha, noha are defined by installers
239 deployment-tools: # mandatory
240 # In the section for each deployment tool, the combinations of the
241 # first three options have to be listed. CI can pick any of the sections.
242 - fuel: # at least one section
243 cpu: intel # optional, default = intel
267 ##############################################################################
269 ##############################################################################
271 # This section will list additional prerequisites. Currently there is only
272 # one case where a scenario has additional prerequisites to the Pharos spec.
273 # Open-O deployment requires 64GB of memory while Pharos spec requires 32GB.
274 # In general it should be preferred to issue such requirements to pharos
275 # using the pharos change request process, but in some cases in might be
276 # better to specify additional prerequisites.
277 # Another use case for these prerequisites will be usage of specilized
278 # hardware, e.g. for acceleration. This needs further study.
280 prerequisites: # The section can be empty or omitted.
281 - controller-node: # Prerequisites might be different
282 RAM: 128GB # optional, just to give examples
284 features: # optional, see example below
290 - jumphost: # Prerequisites can be given also for jumphost
294 ##############################################################################