Merge "Scenario Lifecycle Document - update chapter 5 Creating Scenarios"
authorUlrich Kleber <ulrich.kleber@huawei.com>
Thu, 22 Jun 2017 08:56:02 +0000 (08:56 +0000)
committerGerrit Code Review <gerrit@opnfv.org>
Thu, 22 Jun 2017 08:56:02 +0000 (08:56 +0000)
INFO
docs/scenario-lifecycle/current-status.rst
docs/scenario-lifecycle/scenario-overview.rst
docs/scenario-lifecycle/scenario-tree-danube.png [new file with mode: 0644]
scenarios/examples/sdf-fdio-example.yaml [new file with mode: 0644]
scenarios/templates/sdf-template.yaml [new file with mode: 0644]

diff --git a/INFO b/INFO
index ee23ff4..74c1bec 100644 (file)
--- a/INFO
+++ b/INFO
@@ -1,9 +1,6 @@
 Project: Continuous Integration (Octopus)
 Project Creation Date: December 9, 2014
-Project Category: Integration&Testing
-Lifecycle State: Incubation
-Primary Contact: ulrich.kleber@huawei.com
-Project Lead: ulrich.kleber@huawei.com (temporary)
+Project Lead: ulrich.kleber@huawei.com
 Jira Project Name: Continuous Integration Project
 Jira Project Prefix: OCTO
 Mailing list tag [octopus]
@@ -13,13 +10,10 @@ Repository: octopus
 Committers:
 dradez@redhat.com
 jiang.zhifeng@zte.com.cn
-stefan.k.berg@ericsson.com
-cm-r@hp.com
-sudhak@hpe.com
+cm-r@hpe.com
 ulrich.kleber@huawei.com
 fatih.degirmenci@ericsson.com
-Iben.Rodriguez@spirent.com
-xyzjerry@gmail.com:
+Iben.Rodriguez@gmail.com
 
 Link to TSC approval of the project: http://meetbot.opnfv.org/meetings/opnfv-meeting/
 Link(s) to approval of additional submitters:
@@ -35,3 +29,7 @@ Huqiqi, Zhangyu and Weshayutin stepped down as committers
 pals@cisco.com removed from committer list by TSC decisions, see 
 https://wiki.opnfv.org/wiki/tsc#october_20_2015
 Email address for sudhak@hpe.com updated
+
+Email address for cm-r@hpe.com and iben.rodriguez@gmail.com updated
+sudha and jerry removed after not responding for one year.
+Stefan stepped down https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-May/016465.html
index 08a3776..c8da13a 100644 (file)
@@ -6,7 +6,8 @@
 Current Status
 ---------------
 
-tdb: this chapter will summarize the scenario analysis.
+This chapter summarizes the scenario analysis to provide some background.
+It also defines the way to introduce the scenario processes.
 
 Arno
 ^^^^^^^^
@@ -18,31 +19,55 @@ that could be deployed in two ways, by the two installers available in Arno.
 Brahmaputra
 ^^^^^^^^^^^^^^^^
 
-tbd
+In Brahmaputra, we added options for SDN (ONOS, OCL) and some optional
+features (sfc, sdnvpn, kvm, l3 enabled ODL).
+Thus we had 9 scenarios, some of them to be deployed with 2 installers,
+that planned to participate in the release. Not all of them succeeded.
 
 Colorado
 ^^^^^^^^^^^^
 
-tbd
+In Colorado more components and features were added to a total of 17
+combinations of components and features. Some were supported by one
+of the four installers, others by multiple installers. In addition HA
+and NOHA options were defined.
+This lead to 28 combinations that planned to participate.
 
 Danube
 ^^^^^^^^^^
 
-tbd: Analysis of the 58 scenarios
-The analysis can be found in the slides at
-https://wiki.opnfv.org/display/INF/Scenario+Consolidation
-and will be explain with some text here.
-The text will also use the diagrams from the slides, e.g.
-show a scenario tree:
+In Danube the number of combinations of components and features increased
+to 24, but since installer support increased and more scenarios planned
+to provide HA and NOHA options, the number of combinations was 54.
 
-.. figure:: scenario-tree.png
+In addition to that some scenarios were defined later in during development
+and some scenarios worked on ARM support.
 
-and an idea about possible generic scenarios:
+This created the need to better understand relationships and
+incompatibilities of the scenarios to drive for a manageable process
+for scenarios.
 
-.. figure:: scenario-tree+idea.png
+As a result the relationship between the scenarios can be
+visualized by a scenario tree.
 
-as well as possible ways to reach this.
+.. figure:: scenario-tree-danube.png
 
+The process for generic and specific scenarios is not in place for the
+Danube release yet. But the different branches of the scenario tree
+provide the candidates to define generic scenario during the timeframe
+of the next release.
+
+Euphrates
+^^^^^^^^^^
+
+tbd: statistics on Euphrates Scenarios
+
+During Euphrates timeframe, dynamic POD allocation is introduced in CI.
+This is a prerequisite to make use of the SDF in the CI pipeline.
+Therefore in this timeframe, scenario processes are introduced only in
+a documentation way and as support for release management.
+
+Also the definition of generic scenarios can be done.
 
 
 
index 9c9c508..4a7ff7a 100644 (file)
@@ -14,77 +14,146 @@ Overview
 Problem Statement:
 ^^^^^^^^^^^^^^^^^^^
 
-OPNFV provides the NFV reference platform in different variants, using different
-upstream open source projects.
-In many cases this includes also different upstream projects providing similar or
-overlapping functionality.
+OPNFV provides the NFV reference platform in different variants, where
+each variant is called a "scenario".
 
-OPNFV introduces scenarios to define various combinations of components from upstream
-projects or configuration options for these components.
+OPNFV introduces scenarios in order to provide a way to deploy the stack
+using different combinations of upstream components, or to provide
+different sets of pre-defined configuration options for these
+components.
 
-The number of such scenarios has increased over time, so it is necessary to clearly
-define how to handle the scenarios.
+In some cases a scenario is introduced in order to provide isolation of
+a specific development effort from other ongoing development efforts,
+similar to the purpose of a branch in a code repository.
 
-Introduction:
+A certain amount of effort and resources is required in order to include
+a scenario in a release. The number of scenarios has increased over
+time, so it is necessary to identify ways to manage the number of
+scenarios and to avoid that their number grows infinitely. To enable
+this, we have to clearly define how to handle the lifecycle of
+scenarios, i.e. how to create, how to terminate, etc.
+
+
+Scenario types:
 ^^^^^^^^^^^^^^^^^^^
 Some OPNFV scenarios have an experimental nature, since they introduce
-new technologies that are not yet mature enough to provide a stable release.
-Nevertheless there also needs to be a way to provide the user with the
-opportunity to try these new features in an OPNFV release context.
+new technologies or features that are not yet mature or well integrated
+enough to provide a stable release. Nevertheless there also needs to be
+a way to provide the user with the opportunity to try these new features
+in an OPNFV release context.
 
 Other scenarios are used to provide stable environments for users
-that wish to build products or live deployments on them.
+desiring a certain combination of upstream components or interested in
+particular capabilities or use cases.
 
-OPNFV scenario lifecycle process will support this by defining two types of scenarios:
+The new OPNFV scenario lifecycle process proposed herein will support
+this by defining two types of scenarios:
 
 * **Generic scenarios** cover a stable set of common features provided
-  by different components and target long-term usage.
-* **Specific scenarios** are needed during development to introduce new upstream
-  components or new features.
-  They are intended to merge with other specific scenarios
-  and bring their features into at least one generic scenario.
-
-OPNFV scenarios are deployed using one of the installer tools.
-A scenario can be deployed by multiple installers and the result will look
-very similar but different. The capabilities provided by the deployments
-should be identical. Results of functional tests should be the same,
+by different components and target long-term usage and maintenance of
+the scenario. Only stable versions of upstream components are allowed to
+be deployed in a generic scenario. Across all generic scenarios in a
+given OPNFV release, the same version of a given upstream component
+should be deployed. Creation of generic scenarios and promotion of
+specific to generic scenario requires TSC approval, see section 5.
+Generic scenarios will get priority over specific scenarios in terms of
+maintenance effort and CI resources.
+
+* **Specific scenarios** are needed during development to introduce new
+upstream components or new features. They are typically derived from a
+generic scenario and are intended to bring their features back into the
+parent generic scenario once they are mature enough. It is also possible
+that multiple specific scenarios are merged before bringing them back to
+the parent scenario, for example in order to test and develop the
+integration of two specific features in isolation. Specific scenarios
+can consume unreleased upstream versions or apply midstream patches.
+Creation of specific scenarios is not gated, but if a project intends to
+release a specific scenario, it has to indicate that in its release plan
+at milestone MS1. The scenario itself can be created at any time, by
+means of a simple request by a PTL to the release manager.
+
+OPNFV scenarios are deployed using one of the OPNFV installer tools.
+Deploying a scenario will normally be supported by multiple installers.
+The capabilities provided by the resulting deployments should be
+identical. The set of tests to run and their results should be the same,
 independent of the installer that had been used. Performance or other
-behavioral aspects could be different.
-The scenario lifecycle process will also define how to document which installer
-can be used for a scenario and how the CI process can trigger automatic deployment
-for a scenario via one of the supported installers.
+behavioral aspects outside the scope of existing OPNFV tests could be
+different.
+
 
-When a developer decides to define a new scenario, he typically will take one
-of the existing scenarios and does some changes, such as:
+Parent-child and sibling relations:
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When a developer decides to define a new scenario, he typically will
+take one of the existing scenarios and do some changes, such as:
 
 * add additional components
 * change a deploy-time configuration
-* use a component in a more experimental version
+* use a component in a more experimental version or with midstream
+patches applied
+
+In this case the already existing scenario is called a "parent" and the
+new scenario would be a "child".
+
+Typically parent scenarios are generic scenarios, but it is possible to
+derive from specific scenarios as well. it is expected that the child
+scenario develops its additions over some time up to a sufficient
+maturity, and then merges back to the parent. This way a continuous
+evolution of the generic scenarios as well as a manageable overall
+number of scenairos is ensured.
+
+In some cases a child scenario will diverge from its parent in a way
+that cannot easily be combined with the parent. Therefore, is is also
+possible to "promote" a scenario from specific to generic. If this is
+foreseeable upfront, the specific scenario can also be derived as a
+sibling rather that child.
+
+Promoting a scenario from specific to generic or creating a new generic
+scenario requires TSC approval. This document defines a process for
+this, see section 5.
 
-In this case the already existing scenario is called a "parent" and the new
-scenario a "child".
 
-Typically parent scenarios are generic scenarios, but this is not mandated.
-In most times the child scenario will develop the new functionality over some
-time and then try to merge its configuration back to the parent.
-But in other cases, the child will introduce a technology that cannot easily
-be combined with the parent.
-For this case this document will define how a new generic scenario can be created.
+Scenario deployment options:
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Many OPNFV scenarios can be deployed in a HA (high availability) or non-HA
-configuration.
-HA configurations deploy some components according to a redundancy model,
-as the components support.
-In these cases multiple deployment options are defined for the same scenario.
+Many OPNFV scenarios can be deployed in different variants that do not
+justify creation of separate scenarios. An example would be HA (high
+availability) or non-HA configuration of otherwise identical scenarios.
+HA configurations deploy some components according to a redundancy
+model. Deployment options will also be used if the same scenario can be
+deployed on multiple types of hardware, i.e. Intel and ARM.
 
-Deployment options will also be used if the same scenario can be deployed
-on multiple types of hardware, i.e. Intel and ARM.
+In these cases multiple deployment options are defined for the same
+scenario. The set of distinguishable deployment option types (e.g.
+redundancy, processor architecture, etc.) will be pre-determined and
+each scenario will have to define at least one option for each option
+type.
+
+It is emphasized that virtual deployments vs. bare-metal deployments are
+intentionally not considered as deployment options. This should be a
+transparent feature of the installer based on the same scenario
+definition.
+
+For generic scenarios, there are certain expectations on the set of
+supported deployment options, e.g. a generic scenario should support at
+least an HA deployment and preferably both HA and non-HA.
+
+
+Scenario descriptor file:
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Every scenario will be described in a scenario descriptor yaml file.
 This file shall contain all the necessary information for different users, such
 as the installers (which components to deploy etc.),
-the ci process (to find the right resources),
-the test projects (to select correct test cases), etc.
+the ci process (resource requirements in order to identify the right pod, machines, etc.).
+
+The scenario descriptor file will also document which installer
+can be used for a scenario and how the CI process can trigger automatic deployment
+for a scenario via one of the supported installers.
+
+
+MANO scenarios:
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 In early OPNFV releases, scenarios covered components of the infrastructure,
 that is NFVI and VIM.
diff --git a/docs/scenario-lifecycle/scenario-tree-danube.png b/docs/scenario-lifecycle/scenario-tree-danube.png
new file mode 100644 (file)
index 0000000..54c111e
Binary files /dev/null and b/docs/scenario-lifecycle/scenario-tree-danube.png differ
diff --git a/scenarios/examples/sdf-fdio-example.yaml b/scenarios/examples/sdf-fdio-example.yaml
new file mode 100644 (file)
index 0000000..cbac4fb
--- /dev/null
@@ -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 (file)
index 0000000..81265e8
--- /dev/null
@@ -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
+
+##############################################################################