+---
##############################################################################
# Copyright (c) 2017 Huawei and others.
# ulrich.kleber@huawei.com
#
# metadata (owner, history, description)
# list of components (names, versions, submodules)
-# deployment options (HA/NOHA, hardware&virtualization, installers, configurations)
+# deployment options (HA/NOHA, hardware&virtualization, installers,
+# configurations)
# other prerequisites (e.g. memory requirement more than pharos spec)
#
# More details can be found in the scenario lifecycle document.
##############################################################################
##############################################################################
-# scenario meta-data # Metadata describing this sdf.yaml file and the scenario
- # history and purpose.
+# scenario meta-data # Metadata describing this sdf.yaml file and the
+# scenario history and purpose.
scenario-metadata:
name: SDF-Template # mandatory
-# This is a free name.
-# For Generic scenarios, the main distiguishing components can be included in
-# the name. The name will be approved by TSC when the generic scenario is
-# established. Examples: OS-ODL-OVSNSH, OS-ONOS, OS-ODL-FDIO,
-# OS-OVSBasic, OS-FDIOBasic, ...
-# For specific scenarios, the name should characterize the main
-# feature that is implemented here. Examples: Bgpvpn, Netvirt-gbp-vpp,
-# Dpdk-bar, Onos-sfc, ...
-# Final rules for naming will be set by the lifecycle document and TSC approval.
+ # This is a free name.
+ # For Generic scenarios, the main distiguishing components can be included in
+ # the name. The name will be approved by TSC when the generic scenario is
+ # established. Examples: OS-ODL-OVSNSH, OS-ONOS, OS-ODL-FDIO,
+ # OS-OVSBasic, OS-FDIOBasic, ...
+ # For specific scenarios, the name should characterize the main
+ # feature that is implemented here. Examples: Bgpvpn, Netvirt-gbp-vpp,
+ # Dpdk-bar, Onos-sfc, ...
+ # Final rules for naming will be set by the lifecycle document and TSC
+ # approval.
title: "SDF template" # mandatory
-# descriptive text title maximum 10-12 words telling the main purpose
+ # descriptive text title maximum 10-12 words telling the main purpose
generic-scenario: false # optional, default = false
version: 1.0.6 # mandatory
-# version number of the sdf, three digits separated with dots
- creation-date: 2017-05-09 # mandatory
-# creation of this sdf file version
+ # version number of the sdf, three digits separated with dots
+ creation-date: 2017-05-09 # mandatory
+ # creation of this sdf file version
# Please add a clear description of the purpose of the scenario, including
# the main benefits and major features (mandatory).
# If applicable, the parent scenario should be mentioned.
opnfv-release: euphrates # mandatory
-# the first opnfv release, the scenario was introduced
+ # the first opnfv release, the scenario was introduced
opnfv-version:
- begins: 5.1.0 # mandatory
-# the first opnfv version, the scenario was released with
+ # the first opnfv version, the scenario was released with
- ends: 7.3.0 # optional
-# the last opnfv version that supports this scenario. Typically the features
-# of the scenario should have been merged to generic scenarios then
- owner: Ulrich Kleber, ulrich.kleber@huawei.com # mandatory
+ # the last opnfv version that supports this scenario. Typically the features
+ # of the scenario should have been merged to generic scenarios then
+ owner: Ulrich Kleber, ulrich.kleber@huawei.com # mandatory
# author of this file and thus owner of the scenario
# Add additional contact persons e.g. from installers or major components
# components
# All components/submodules/features in the list shall be deployed
components: # mandatory section
-# In this section all components are listed together with their version.
-# For some components in addtion submodules or optional features can be listed.
+ # In this section all components are listed together with their version.
+ # For some components in addtion submodules or optional features can
+ # be listed.
- sdn-controller: # optional, default = no sdn controller
-# most important categories here are: sdn-controller, cloud-controller,
-# storage, virtual-switching, dataplane, nfvo, vnfm, but new categories
-# can be introduced any time.
-# Every component to be deployed should be listed with such a section.
-# If the component has submodules or optional features, they also need
-# to be listed.
- type: opendaylight # mandatory, other options e.g.onos, ocl, ovn
- release: boron # either release or version or both must be given
-# upstream version, human readable release name
- version: 5.0.1
-# exact semantic version including patch level
-# Normally installers will not be able to pick exact semantic versions, but
-# if the scenario requires specific versions, this can be checked offline.
-# Following syntax variants can be allowed as well:
-# version: 5.*.*
-# version: ">5.0.3"
- features: # optional
-# additional feature configurations as recognized by the installers.
- - odl_l2
- - sfc
- - bgpvpn
+ # most important categories here are: sdn-controller, cloud-controller,
+ # storage, virtual-switching, dataplane, nfvo, vnfm, but new categories
+ # can be introduced any time.
+ # Every component to be deployed should be listed with such a section.
+ # If the component has submodules or optional features, they also need
+ # to be listed.
+ type: opendaylight # mandatory, other options e.g.onos, ocl, ovn
+ release: boron # either release or version or both must be given
+ # upstream version, human readable release name
+ version: 5.0.1
+ # exact semantic version including patch level
+ # Normally installers will not be able to pick exact semantic versions, but
+ # if the scenario requires specific versions, this can be checked offline.
+ # Following syntax variants can be allowed as well:
+ # version: 5.*.*
+ # version: ">5.0.3"
+ features: # optional
+ # additional feature configurations as recognized by the installers.
+ - odl_l2
+ - sfc
+ - bgpvpn
- - storage: # optional
+ - storage: # optional
type: ceph
- - cloud-controller: # seems to me mandatory
- type: openstack # other option could be kubernetes
- release: ocata # either release or version or both must be given
+ - cloud-controller: # seems to me mandatory
+ type: openstack # other option could be kubernetes
+ release: ocata # either release or version or both must be given
version: 15.0.0
-# An OPNFV version can go only with one openstack version. Typically installers
-# cannot pick different openstack version, but this can be checked offline.
+ # An OPNFV version can go only with one openstack version.
+ # Typically installers cannot pick different openstack version,
+ # but this can be checked offline.
modules: # optional
-# Installers have a basic set of modules that are deployed by default. Those
-# can be listed optional. Scenario owners can list additional optional modules
-# with their name as on https://wiki.openstack.org/software/project-navigator,
-# but with lower case and dashes, Examples: tacker, kuryr, horizon, vitrage,
-# chef-openstack, openstack-charms, etc.
-# Independent of big tent, modules can be used if installers support their deployment.
+ # Installers have a basic set of modules that are deployed by
+ # default. Those can be listed optional. Scenario owners can
+ # list additional optional modules with their name as on
+ # https://wiki.openstack.org/software/project-navigator, but
+ # with lower case and dashes, Examples: tacker, kuryr, horizon,
+ # vitrage, chef-openstack, openstack-charms, etc.
+ # Independent of big tent, modules can be used if installers
+ # support their deployment.
- nova
- cinder
- horizon
- glance
- heat
- neutron:
- features: # In some cases features need to be listed specifically
- - bgpvpn # listing service plugins as neutron features makes
-# it easier for installers, they don't need to take this information from the features
-# field in the sdn-controller.
+ features: # In some cases features need to be listed specifically
+ - bgpvpn # listing service plugins as neutron features makes
+ # it easier for installers, they don't need to take this
+ # information from the features field in the sdn-controller.
- aodh
- tacker
- congress
- - virtual-switching: # optional
-# showing with this example how to include a separate configuration file for this
+ - virtual-switching: # optional
+ # showing with this example how to include a separate
+ # configuration file for this
type: ovs
- release: xx # either release or version or both must be given
+ release: xx # either release or version or both must be given
version: 2.6.1
- features: # optional
+ features: # optional
- vsperf:
file: scenarios/ovs-config.yaml
# this file then should contain additional configurations to use like
# Please note, the template cannot show all possible options here. There will be
# more in an additional document.
# Correct usage of the keywords/options will be enforced by a schema.
-# Also note that some component related deployment information will be in the options
-# section.
+# Also note that some component related deployment information will be
+# in the options section.
##############################################################################
##############################################################################
features: # optional
- dpdk
- other
-#$$$$ Discussion open whether we need features here after adding them in roles section
+ # $$$$ Discussion open whether we need features here after adding
+ # them in roles section
- baremetal:
architecture: arm64
- virtual:
-#$$$$ Discussion open whether this is necessary here.
+ # $$$$ Discussion open whether this is necessary here.
architecture: x86_64
features:
- xyz
-#$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
-# Discussion open how to specify the distribution of components on nodes.
-# Three proposals:
-# 1. specify availability options ha, noha by placing functions on nodes
-# 2. specify roles like compute-node, controller-node and only their number,
-# thus avoid coupling with hostnames and more flexible mapping to different
-# sizes of PODs.
-# 3. Leave it to installers and just specify whether ha or noha are supported
-
-#$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
-# Proposal 1:
+ # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
+ # Discussion open how to specify the distribution of components on nodes.
+ # Three proposals:
+ # 1. specify availability options ha, noha by placing functions on nodes
+ # 2. specify roles like compute-node, controller-node and only their number,
+ # thus avoid coupling with hostnames and more flexible mapping to different
+ # sizes of PODs.
+ # 3. Leave it to installers and just specify whether ha or noha are supported
+ # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
+ # Proposal 1:
availability: # mandatory
-# here the configuration for a HA and NONHA deployment is described.
-# It is similar to what compass has in host section (minus the POD info),
-# or fuel in the dea-override-config or dha-override-config
+ # here the configuration for a HA and NONHA deployment is described.
+ # It is similar to what compass has in host section (minus the POD info),
+ # or fuel in the dea-override-config or dha-override-config
- ha: # minimum one of ha or noha must be specified
nodes: # a description like this is mandatory
- - name: [host1, host2, host3] # avoid to list the same multiple times
+ - name: [host1, host2, host3] # avoid to list the same multiple times
roles:
- - openstack-controller # took this from compass. Is it sufficient?
+ # took this from compass. Is it sufficient?
+ - openstack-controller
- odl
- ceph-adm
- ceph-mon
- openstack-compute
- ceph-osd
-#$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
-# Proposal 2:
- roles: # mandatory
+ # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
+ # Proposal 2:
+ roles: # mandatory
- controller-node:
- components: # list all components that are deployed here.
+ components: # list all components that are deployed here.
- openstack: control
- opendaylight
- ceph: [ceph-adm, ceph-mon]
- ovs
hardware-features:
- dpdk
- - jump-host: # some scenarios, e.g. MANO might deploy components here
+ - jump-host: # some scenarios, e.g. MANO might deploy components here
- role-distribution: # mandatory
+ role-distribution: # mandatory
- ha:
controller-node: 3
compute-node: 2
compute-node: 4
jump-host: 1
-#$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
-# Proposal 3:
-# no specification of nodes/roles here. ha, noha are defined by installers
+ # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
+ # Proposal 3:
+ # no specification of nodes/roles here. ha, noha are defined by installers
deployment-tools: # mandatory
-# In the section for each deployment tool, the combinations of the
-# first three options have to be listed. CI can pick any of the sections.
+ # In the section for each deployment tool, the combinations of the
+ # first three options have to be listed. CI can pick any of the sections.
- fuel: # at least one section
- cpu: intel # optional, default = intel
- pod: baremetal
- availability: ha
+ cpu: intel # optional, default = intel
+ pod: baremetal
+ availability: ha
- fuel:
- cpu: intel
- pod: virtual
- availability: ha
+ cpu: intel
+ pod: virtual
+ availability: ha
- fuel:
- cpu: intel
- pod: virtual
- availability: noha
+ cpu: intel
+ pod: virtual
+ availability: noha
- fuel:
- cpu: arm
- pod: baremetal
- availability: noha
+ cpu: arm
+ pod: baremetal
+ availability: noha
- compass:
- cpu: intel
- pod: baremetal
- availability: ha
+ cpu: intel
+ pod: baremetal
+ availability: ha
- joid:
- cpu: intel
- pod: baremetal
- availability: ha
+ cpu: intel
+ pod: baremetal
+ availability: ha
##############################################################################
Code Review / octopus.git / commitdiff