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 ##############################################################################