--- ############################################################################## # Copyright (c) 2017 Huawei and others. # ulrich.kleber@huawei.com # All rights reserved. This program and the accompanying materials # are made available under the terms of the Apache License, Version 2.0 # which accompanies this distribution, and is available at # http://www.apache.org/licenses/LICENSE-2.0 ############################################################################## ############################################################################## # Description: # This is the template for all scenario descriptor files (sdf) # Every OPNFV scenario is described in an sdf.yaml located in the # scenarios folder in Octopus repo. # The sdf is provided by the scenario owner and consumed by CI, deployment # tools and test frameworks. # # Main sections: # # metadata (owner, history, description) # list of components (names, versions, submodules) # 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-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. title: "SDF template" # mandatory # 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 # 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 opnfv-version: - begins: 5.1.0 # mandatory # 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 # 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. - 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 - 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 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. 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. - 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. - aodh - tacker - congress - 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 version: 2.6.1 features: # optional - vsperf: file: scenarios/ovs-config.yaml # this file then should contain additional configurations to use like # hugepage-size, iommu, ... # it will be treated like a C #include statement. # 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. ############################################################################## ############################################################################## # deployment options # In this section, CI will select one of the listed options and needs to pass # the information to the installer via a parameter or environment. deployment-options: # mandatory deployment-types: # at least one section must be provided - baremetal: architecture: x86_64 features: # optional - dpdk - other # $$$$ Discussion open whether we need features here after adding # them in roles section - baremetal: architecture: arm64 - virtual: # $$$$ 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: 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 - 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 roles: # took this from compass. Is it sufficient? - openstack-controller - odl - ceph-adm - ceph-mon - name: [host4, host 5] roles: - openstack-compute - ceph-osd - noha: hosts: - name: host1 roles: - openstack-controller - odl - ceph-adm - ceph-mon - name: host2 roles: - openstack-compute - ceph-osd - name: host3 roles: - openstack-compute - ceph-osd # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ # Proposal 2: roles: # mandatory - controller-node: components: # list all components that are deployed here. - openstack: control - opendaylight - ceph: [ceph-adm, ceph-mon] - ovs - compute-node: components: - openstack: compute - ceph: ceph-osd - ovs hardware-features: - dpdk - jump-host: # some scenarios, e.g. MANO might deploy components here role-distribution: # mandatory - ha: controller-node: 3 compute-node: 2 jump-host: 1 - noha: controller-node: 1 compute-node: 4 jump-host: 1 # $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ # 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. - fuel: # at least one section cpu: intel # optional, default = intel pod: baremetal availability: ha - fuel: cpu: intel pod: virtual availability: ha - fuel: cpu: intel pod: virtual availability: noha - fuel: cpu: arm pod: baremetal availability: noha - compass: cpu: intel pod: baremetal availability: ha - joid: cpu: intel pod: baremetal availability: ha ############################################################################## ############################################################################## # Prerequisites # This section will list additional prerequisites. Currently there is only # one case where a scenario has additional prerequisites to the Pharos spec. # Open-O deployment requires 64GB of memory while Pharos spec requires 32GB. # In general it should be preferred to issue such requirements to pharos # using the pharos change request process, but in some cases in might be # better to specify additional prerequisites. # Another use case for these prerequisites will be usage of specilized # hardware, e.g. for acceleration. This needs further study. prerequisites: # The section can be empty or omitted. - controller-node: # Prerequisites might be different RAM: 128GB # optional, just to give examples cpu: dual-core features: # optional, see example below - compute-node: RAM: 128GB cpu: dual-core features: - dpdk - jumphost: # Prerequisites can be given also for jumphost RAM: 128GB cpu: dual-core ##############################################################################