--- /dev/null
+---
+##############################################################################
+# 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:
+ # fuel support shall be added soon
+ - apex:
+ cpu: intel
+ pod: baremetal
+ availability: ha
+##############################################################################
+
+##############################################################################
+# Prerequisites
+# No other prerequisites
+##############################################################################
--- /dev/null
+---
+##############################################################################
+# 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 an example for a MANO scenario
+# It illustrates how MANO components can test orchestration capabilities
+# together with various infrastructure scenarios.
+# This way, the SDF describes the MANO components (NFVO and VNFM) only. For
+# the infrastructure (NFVI and VIM) part another scenario is just referenced;
+# that scenario is deployed independently in a separate deployment step, and
+# can be deployed even using a different installer tool.
+#
+# More details can be found in the scenario lifecycle document.
+# http://artifacts.opnfv.org/octopus/docs/scenario-lifecycle/index.html
+##############################################################################
+
+##############################################################################
+# scenario meta-data: Metadata describing this sdf.yaml file and the
+# scenario history and purpose, like in any other scenario descriptor
+scenario-metadata:
+ name: orchestra-example
+ title: "orchestra main scenario"
+ generic-scenario: false
+ version: 1.0.3
+ creation-date: 2017-07-13
+ # This scenario integrates the main open-baton NFVO components to OPNFV
+ # infrastructure.
+ # In the first step, no sdn controller scenarios are supported, but only
+ # os-nosdn-nofeature and os-nosdn-ovs, installed by compass.
+ opnfv-release: euphrates
+ opnfv-version:
+ - begins: 5.1.0
+ owner: Ulrich Kleber, ulrich.kleber@huawei.com
+
+##############################################################################
+
+##############################################################################
+# components
+components:
+ - nfvo:
+ type: open-baton
+ version: 3.0
+ # here a list of optional features or artifacts to deploy could follow
+
+ - vnfm:
+ type: juju
+ # juju doesn't have release name
+ version: 2.2
+
+ - opnfv-infrastructure:
+ release: euphrates # this determines also ocata as openstack version
+ version: 5.0.0
+ scenarios:
+ - os-nosdn-nofeature:
+ options:
+ - availability: [HA, NOHA]
+ - tools: [compass, joid]
+ # this is for the example. In first step only joid will work
+ - os-nosdn-ovs:
+ options:
+ - availability: [HA, NOHA]
+ - tools: compass
+
+##############################################################################
+
+##############################################################################
+# deployment options
+
+deployment-options:
+ deployment-types:
+ - baremetal:
+ architecture: x86_64
+
+ # $$$$ following proposal 2 from the template (patchset 6)
+ roles:
+ - jump-host:
+ components:
+ - open-baton
+ - juju-controller
+ - controller-node:
+ components:
+ - juju-client
+ # this is in addition to the components defined in the
+ # opnfv-infrastructure scenario.
+ - compute-node: # no additional component to be deployed here
+
+ role-distribution:
+ - ha:
+ controller-node: 3
+ compute-node: 2
+ jump-host: 1
+ - noha:
+ controller-node: 1
+ compute-node: 4
+ jump-host: 1
+
+ deployment-tools:
+ # Please note that the component "opnfv-infrastructure" specified their
+ # own deployment tools and options. Definition here is related only
+ # for the nfvo and vnfm components specified above.
+
+ - joid:
+ cpu: intel
+ pod: baremetal
+ availability: HA
+ - joid:
+ cpu: intel
+ pod: baremetal
+ availability: NOHA
+ - joid:
+ cpu: intel
+ pod: virtual
+ availability: NOHA
+
+##############################################################################
+
+##############################################################################
+# Prerequisites
+prerequisites:
+ RAM: 128GB
--- /dev/null
+---
+##############################################################################
+# 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
+
+##############################################################################
Code Review / pharos.git / commitdiff