diff options
Diffstat (limited to 'scenarios')
| -rw-r--r-- | scenarios/examples/sdf-fdio-example.yaml | 15 | ||||
| -rw-r--r-- | scenarios/templates/sdf-template.yaml | 235 |
2 files changed, 130 insertions, 120 deletions
diff --git a/scenarios/examples/sdf-fdio-example.yaml b/scenarios/examples/sdf-fdio-example.yaml index cbac4fb..7ea0ba8 100644 --- a/scenarios/examples/sdf-fdio-example.yaml +++ b/scenarios/examples/sdf-fdio-example.yaml @@ -1,3 +1,4 @@ +--- ############################################################################## # Copyright (c) 2017 Huawei others. # ulrich.kleber@huawei.com @@ -21,7 +22,7 @@ scenario-metadata: title: fdio odl basic for devops generic-scenario: false version: 1.0.0 - creation-date: 2017-03-16 + creation-date: 2017-03-16 # This scenario introduces fd.io with odl and a basic feature set. # It is derived from parent odl_l2 nofeature. In a next step, odl_l2 and # old_l3 functionality shall be merged and provide sfc as well as other @@ -48,7 +49,7 @@ components: - vpp - storage: component-type: ceph - #$$$$ Should we add num-replicas 3 here? + # $$$$ Should we add num-replicas 3 here? - cloud-controller: type: openstack @@ -103,7 +104,7 @@ deployment-options: nodes: - name: host1 roles: - - openstack-controller # need to add fd.io? + - openstack-controller # need to add fd.io? - odl - name: host2 roles: @@ -120,11 +121,11 @@ deployment-options: roles: - openstack-compute deployment-tools: - - apex: - cpu: intel - pod: baremetal - availability: ha # fuel support shall be added soon + - apex: + cpu: intel + pod: baremetal + availability: ha ############################################################################## ############################################################################## diff --git a/scenarios/templates/sdf-template.yaml b/scenarios/templates/sdf-template.yaml index 81265e8..2f0121b 100644 --- a/scenarios/templates/sdf-template.yaml +++ b/scenarios/templates/sdf-template.yaml @@ -1,3 +1,4 @@ +--- ############################################################################## # Copyright (c) 2017 Huawei and others. # ulrich.kleber@huawei.com @@ -19,45 +20,47 @@ # # 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 @@ -67,67 +70,72 @@ scenario-metadata: # 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 @@ -136,8 +144,8 @@ components: # mandatory section # 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. ############################################################################## ############################################################################## @@ -151,35 +159,36 @@ deployment-options: # mandatory 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 @@ -204,11 +213,11 @@ deployment-options: # mandatory - 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] @@ -220,9 +229,9 @@ deployment-options: # mandatory - 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 @@ -232,37 +241,37 @@ deployment-options: # mandatory 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 ############################################################################## |