diff options
| -rw-r--r-- | INFO | 16 | ||||
| -rw-r--r-- | docs/scenario-lifecycle/current-status.rst | 51 | ||||
| -rw-r--r-- | docs/scenario-lifecycle/scenario-overview.rst | 165 | ||||
| -rw-r--r-- | docs/scenario-lifecycle/scenario-tree-danube.png | bin | 0 -> 80299 bytes | |||
| -rw-r--r-- | scenarios/examples/sdf-fdio-example.yaml | 133 | ||||
| -rw-r--r-- | scenarios/templates/sdf-template.yaml | 294 |
6 files changed, 589 insertions, 70 deletions
@@ -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 diff --git a/docs/scenario-lifecycle/current-status.rst b/docs/scenario-lifecycle/current-status.rst index 08a3776..c8da13a 100644 --- a/docs/scenario-lifecycle/current-status.rst +++ b/docs/scenario-lifecycle/current-status.rst @@ -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. diff --git a/docs/scenario-lifecycle/scenario-overview.rst b/docs/scenario-lifecycle/scenario-overview.rst index 9c9c508..4a7ff7a 100644 --- a/docs/scenario-lifecycle/scenario-overview.rst +++ b/docs/scenario-lifecycle/scenario-overview.rst @@ -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 Binary files differnew file mode 100644 index 0000000..54c111e --- /dev/null +++ b/docs/scenario-lifecycle/scenario-tree-danube.png 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 + +############################################################################## |
