diff options
Diffstat (limited to 'scenarios')
| -rw-r--r-- | scenarios/examples/sdf-fdio-example.yaml | 133 | ||||
| -rw-r--r-- | scenarios/templates/sdf-template.yaml | 294 |
2 files changed, 427 insertions, 0 deletions
diff --git a/scenarios/examples/sdf-fdio-example.yaml b/scenarios/examples/sdf-fdio-example.yaml new file mode 100644 index 0000000..cbac4fb --- /dev/null +++ b/scenarios/examples/sdf-fdio-example.yaml @@ -0,0 +1,133 @@ +############################################################################## +# Copyright (c) 2017 Huawei 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 an example for a specific scenario. +# It is derived from: +# apex/config/deploy/os-odl_l2-fdio-ha +############################################################################## + +############################################################################## +# scenario meta-data +scenario-metadata: + name: odl-fdio-devops + title: fdio odl basic for devops + generic-scenario: false + version: 1.0.0 + 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 + # features. + # This scenario will use newer versions of ODL and other upstream components + # than used in Euphrates. It is planned to release it or DevOps use more + # often than regular OPNFV release cycle. + opnfv-release: colorado + opnfv-version: 3.1.0 # the first opnfv version, the scenario was introduced + owner: Frank Brockners, frank.brockners@cisco.com + # Add additional contact persons e.g. from installers or major components + +############################################################################## + +############################################################################## +# components +components: + - sdn-controller: + component-type: opendaylight + release: carbon + version: ">6.0.1" + features: + - odl_l2 + - vpp + - storage: + component-type: ceph + #$$$$ Should we add num-replicas 3 here? + + - cloud-controller: + type: openstack + release: ocata + modules: + - nova + - cinder + - dashboard + - glance + - heat + - neutron + - tacker + - congress + - dataplane: + type: fdio + release: xx + version: 9.9.9 + features: + - performance: + controller-nodes: + kernel: + hugepages: 1024 # decimal number + hugepagesz: 2M # values like 2M, 1G + intel_iommu: 'on' + iommu: pt + isolcpus: 1,2 + vpp: + main-core: 1 + corelist-workers: 2 + uio-driver: uio_pci_generic + compute-nodes: + kernel: + hugepagesz: 2M + hugepages: 2048 + intel_iommu: 'on' + iommu: pt + isolcpus: 1,2 + vpp: + main-core: 1 + corelist-workers: 2 + uio-driver: uio_pci_generic +############################################################################## + +############################################################################## +# deployment options +deployment-options: + deployment-types: # only intel baremetal is supported + - baremetal: + architecture: x86_64 + availability: + - ha: # We support only HA + nodes: + - name: host1 + roles: + - openstack-controller # need to add fd.io? + - odl + - name: host2 + roles: + - openstack-controller + - odl + - name: host3 + roles: + - openstack-controller + - odl + - name: host4 # need to add fd.io? + roles: + - openstack-compute + - name: host5 + roles: + - openstack-compute + deployment-tools: + - apex: + cpu: intel + pod: baremetal + availability: ha + # fuel support shall be added soon +############################################################################## + +############################################################################## +# Prerequisites +# No other prerequisites +############################################################################## diff --git a/scenarios/templates/sdf-template.yaml b/scenarios/templates/sdf-template.yaml new file mode 100644 index 0000000..81265e8 --- /dev/null +++ b/scenarios/templates/sdf-template.yaml @@ -0,0 +1,294 @@ +############################################################################## +# 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: + - openstack-controller # took this from compass. Is it sufficient? + - 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 + +############################################################################## |