From: Julien Date: Mon, 5 Feb 2018 07:31:45 +0000 (+0800) Subject: Add SDF files in Octopus X-Git-Url: https://gerrit.opnfv.org/gerrit/gitweb?a=commitdiff_plain;h=32cb06f2dfb92481feb0f02ef94fc745001963d4;p=pharos.git Add SDF files in Octopus Add SDF files in Octopus to scenarios sub-directories. In the future, we will add schema files for SDF just like PDF/IDF. Change-Id: I248834bc7fe91bfbd8afe4827905f6ebd4f7a5ab Signed-off-by: Julien --- diff --git a/scenarios/README b/scenarios/README new file mode 100644 index 00000000..a858bd7d --- /dev/null +++ b/scenarios/README @@ -0,0 +1 @@ +This folder will contain all scenario descriptor yaml files. diff --git a/scenarios/examples/sdf-fdio-example.yaml b/scenarios/examples/sdf-fdio-example.yaml new file mode 100644 index 00000000..7ea0ba8a --- /dev/null +++ b/scenarios/examples/sdf-fdio-example.yaml @@ -0,0 +1,134 @@ +--- +############################################################################## +# 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 +############################################################################## diff --git a/scenarios/examples/sdf-mano-example.yaml b/scenarios/examples/sdf-mano-example.yaml new file mode 100644 index 00000000..66063163 --- /dev/null +++ b/scenarios/examples/sdf-mano-example.yaml @@ -0,0 +1,128 @@ +--- +############################################################################## +# 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 diff --git a/scenarios/templates/sdf-template.yaml b/scenarios/templates/sdf-template.yaml new file mode 100644 index 00000000..2f0121be --- /dev/null +++ b/scenarios/templates/sdf-template.yaml @@ -0,0 +1,303 @@ +--- +############################################################################## +# 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 + +##############################################################################