Skip to end of metadata
Go to start of metadata

In the following table we collect data for Danube scenarios that will be the basis for scenario consolidation.

Please note that a scenario that is supported by multiple installers is listed in a single row.

The table shall help us to move from scenario ownership by experts for the deployment of a scenario, but by ownership by the project that needs the scenario and knows the details what (and in what configuration, but not how) to deploy and what to test with this scenario. According to this new ownership, each of below 34 scenarios from Danube release should have a single owner, talking to the necessary experts from installers and test team as we agree on technical discussion meeting on January 12, 2017.

See here also new slides summarizing the current discussion and proposing next steps.

Besides details for the definition of generic and specific scenarios and parent-child relations, it includes an analysis of the dependencies between scenarios and a proposal for a scenario tree.


The powerpoint presentation was now transformed to a document that has been reviewed for a first round in gerrit. So see updated information there: 

Also a first draft of the template for SDF (Scenario Descriptor File) is available and in review:

Review comments to the SDF have not yet been updated to the lifecycle document.





(Danube release)

Required by
(Project / Person)

= Owner for features

(Installer / Person)
Remarks and
Ideas for roadmap
k8-nosdn-baremetal-coreJOIDJOID: Artur Tyloch    
k8-nosdn-baremetal-lbJOIDJOID: Artur Tyloch    
k8-nosdn-os-lbJOIDJOID: Artur Tyloch    
os-nosdn-dpdk_ipv6JOID ha&nohaJOID: Artur Tyloch IPv6?  No, this scenario has nothing to do with IPv6 Project
os-nosdn-fdio-haApexApex: Frank Brockners    

Fuel ha&noha,
Apex ha&noha

Fuel:  Raghuveer Reddy,
Apex:  Chou, David J 


Fuel ha&noha,
Apex ha&noha

Fuel:  Raghuveer Reddy,
Apex:  Chou, David J 

os-nosdn-lxdJOID ha&nohaJOID: Artur Tyloch    

Apex ha,
JOID ha&noha,
Fuel ha&noha,
Daisy ha, Compass ha

Apex: Tim Rozet,
JOID: Artur Tyloch,
Fuel: Fedor Zhadaev,
Daisy: Zhijiang Hu,
Compass: Justin chi
   Goal: Generic Scenario
(exceptional case, parent for all OpenStack scenarios)
os-nosdn-ovs-haApexApex: Thomas F Herbert    
os-ocl-nofeature-haJOID ha&nohaJOID: Artur Tyloch    
os-odl_l2-bgpvpn-haApex, FuelApex: Tim Irnich,
Fuel: Tim Irnich
os-odl_l2-fdio-haApex, FuelApex: Frank Brockners,
Fuel: Fedor Zhadaev
os-odl_l2-moon-haCompassCompass: Ruan HEmoon/
Ruan HE
  ownership already with non-installer person
os-odl_l2-nofeature-haJOID ha&noha,
Fuel ha&noha,
Compass ha
JOID: Artur Tyloch,
Fuel: Fedor Zhadaev,
Compass: Justin chi


os-odl_l2-sfc-fdio-haApex, FuelApex: Brady Johnson,
Fuel: Brady Johnson
os-odl_l2-sfc-haApex ha&noha,
Compass ha
Apex: Brady Johnson,
Fuel: Brady Johnson,
Compass: Justin chi
os-odl_l3-fdio-haApex, FuelApex: Frank Brockners,
Fuel: Fedor Zhadaev
os-odl_l3-gluon-nohaApexApex: Georg KunzNetReady /
Georg Kunz
  • ownership already with non-installer person
    • but HIGHLY depends on Apex support
  • potential parent scenarios
    • os-odl_l2-bgpvpn-ha
    • os-odl_l3-nofeature-ha
os-odl_l3-nofeature-haApex ha,
Fuel ha&noha,
Compass ha
Apex: Tim Rozet,
Fuel: Fedor Zhadaev,
Compass: Justin chi
os-odl_l3-ovs-nohaApexApex: Thomas F Herbert OVSNFV?    
os-odl-ovs-haApexApex: Thomas F Herbert OVSNFV?  

Question: should this be named os-odl-l3-ovs-ha
according to our scheme?

(radez) No, I think the _l3 will go away because it's default now.
We've already removed it in our E branch. _l2 is now the exception. 

os-onos-nofeature-haApex, JOID, CompassApex: Tim Rozet,
JOID: Artur Tyloch,
Compass: Justin chi
 ONOSFW   Basic ONOS scenario
os-onos-sfc-haJOID, CompassJOID: Artur Tyloch,
Compass: Justin chi

Parent: os-onos-nofeature-ha

Goal: Create generic scenario for ONOS

os-ovn-nofeature-haApexApex: Tim Rozet OVN4NFV?   
  • No labels


  1. Some comments for consideration in scenario consolidation :

    1)  it would be good to have some identified relationship between the scenarios and which of the EUAG pain points or user EPICs is being addressed by that scenario.

    2) A mapping between scenarios and the upstream components that they use  would be very useful. I suspect that each user has a specific set of upstream components that they have an interest in (e.g. because it is currently deployed)

    3) Scenarios at the moment are all targeted for deployment on Pharos pods, but there may be other infrastructure profiles that need to be considered see the EUAG Pain Point - Infrastructure and the OPNFV Reference Platform

  2. Thanks.

    We moved to review the scenario lifecycle in document format. You could look at the patch creating the document at or the generated html at .

    1) There will not be a 1:1 mapping for most of the pain points to scenarios. I think we have to document mapping of EUAG pain points to project work and scenarios in the wiki of the projects working on the pain points and on the scenarios.

    2) Yes. The scenario descriptor file will include a list of the upstream components used in the scenario, including the versions.

    3) I agree, this is necessary. The syntax for the scenario descriptor file will allow different deployment profiles. OPNFV as a community project has defined the infrastructure variants we want to work on. But that doesn't restrict the usage of the platform. The scenario definition is independent from that. But the usage of the scenario definitions in the OPNFV community will be on Pharos labs. Outside the normal community work, there need to be deployments on larger environments, e.g. 10, 20, 30 servers instead of the 5 of a Pharos lab. The methodology that we currently introduce with POD descriptor files and scenario descriptor files will allow users to use customized files to create larger deployments.