scenarios/templates/sdf-template.yaml

   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 ##############################################################################
   9
  10 ##############################################################################
  11 # Description:
  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.
  17 #
  18 # Main sections:
  19 #
  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)
  24 #
  25 # More details can be found in the scenario lifecycle document.
  26 ##############################################################################
  27
  28 ##############################################################################
  29 # scenario meta-data    # Metadata describing this sdf.yaml file and the scenario
  30                         # history and purpose.
  31 scenario-metadata:
  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
  54   opnfv-version:
  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
  63
  64 ##############################################################################
  65
  66 ##############################################################################
  67 # components
  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
  78 # to be listed.
  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
  82       version: 5.0.1
  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:
  87 #     version: 5.*.*
  88 #     version: ">5.0.3"
  89       features:                 # optional
  90 # additional feature configurations as recognized by the installers.
  91         - odl_l2
  92         - sfc
  93         - bgpvpn
  94
  95   - storage:                    # optional
  96       type: ceph
  97
  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
 101       version: 15.0.0
 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.
 104       modules:                  # optional
 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.
 111         - nova
 112         - cinder
 113         - horizon
 114         - glance
 115         - heat
 116         - neutron:
 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.
 121         - aodh
 122         - tacker
 123         - congress
 124
 125   - virtual-switching:          # optional
 126 # showing with this example how to include a separate configuration file for this
 127       type: ovs
 128       release: xx               # either release or version or both must be given
 129       version: 2.6.1
 130       features:                 # optional
 131         - vsperf:
 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
 140 # section.
 141 ##############################################################################
 142
 143 ##############################################################################
 144 # deployment options
 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
 149     - baremetal:
 150       architecture: x86_64
 151       features:                 # optional
 152         - dpdk
 153         - other
 154 #$$$$ Discussion open whether we need features here after adding them in roles section
 155     - baremetal:
 156       architecture: arm64
 157     - virtual:
 158 #$$$$ Discussion open whether this is necessary here.
 159       architecture: x86_64
 160       features:
 161         - xyz
 162
 163 #$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
 164 # Discussion open how to specify the distribution of components on nodes.
 165 # Three proposals:
 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
 169 #    sizes of PODs.
 170 # 3. Leave it to installers and just specify whether ha or noha are supported
 171
 172 #$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
 173 # Proposal 1:
 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
 181             roles:
 182               - openstack-controller # took this from compass. Is it sufficient?
 183               - odl
 184               - ceph-adm
 185               - ceph-mon
 186           - name: [host4, host 5]
 187             roles:
 188               - openstack-compute
 189               - ceph-osd
 190     - noha:
 191         hosts:
 192           - name: host1
 193             roles:
 194               - openstack-controller
 195               - odl
 196               - ceph-adm
 197               - ceph-mon
 198           - name: host2
 199             roles:
 200               - openstack-compute
 201               - ceph-osd
 202           - name: host3
 203             roles:
 204               - openstack-compute
 205               - ceph-osd
 206
 207 #$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
 208 # Proposal 2:
 209   roles:                        # mandatory
 210     - controller-node:
 211         components:             # list all components that are deployed here.
 212           - openstack: control
 213           - opendaylight
 214           - ceph: [ceph-adm, ceph-mon]
 215           - ovs
 216     - compute-node:
 217         components:
 218           - openstack: compute
 219           - ceph: ceph-osd
 220           - ovs
 221         hardware-features:
 222           - dpdk
 223     - jump-host:                # some scenarios, e.g. MANO might deploy components here
 224
 225   role-distribution:            # mandatory
 226     - ha:
 227         controller-node: 3
 228         compute-node: 2
 229         jump-host: 1
 230     - noha:
 231         controller-node: 1
 232         compute-node: 4
 233         jump-host: 1
 234
 235 #$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
 236 # Proposal 3:
 237 # no specification of nodes/roles here. ha, noha are defined by installers
 238
 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
 244          pod: baremetal
 245          availability: ha
 246     - fuel:
 247          cpu: intel
 248          pod: virtual
 249          availability: ha
 250     - fuel:
 251          cpu: intel
 252          pod: virtual
 253          availability: noha
 254     - fuel:
 255          cpu: arm
 256          pod: baremetal
 257          availability: noha
 258     - compass:
 259          cpu: intel
 260          pod: baremetal
 261          availability: ha
 262     - joid:
 263          cpu: intel
 264          pod: baremetal
 265          availability: ha
 266
 267 ##############################################################################
 268
 269 ##############################################################################
 270 # Prerequisites
 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.
 279
 280 prerequisites:                  # The section can be empty or omitted.
 281   - controller-node:            # Prerequisites might be different
 282       RAM: 128GB                # optional, just to give examples
 283       cpu: dual-core
 284       features:                 # optional, see example below
 285   - compute-node:
 286       RAM: 128GB
 287       cpu: dual-core
 288       features:
 289         - dpdk
 290   - jumphost:                   # Prerequisites can be given also for jumphost
 291       RAM: 128GB
 292       cpu: dual-core
 293
 294 ##############################################################################