1. Scenario Considerations
12 October 2016

2. Problem Statement Scenario Names Scenario Consolidation
Already rather complex (e.g. os-odl_l3-vpp-ha)
Feature combinations lead to more complexity
Adding MANO components leads to too long names
Scenario Consolidation
High number of scenarios needs too many resources
Some scenarios just contain each other, but are necessary for development flow.
Can we define development-scenarios vs. release-scenarios?
Can some scenarios use the same build artifacts?
17/09/2018

3. Scenario Naming 17/09/2018 Current scenario naming rule*
Short scenario names should follow the scheme below.
os-[controller]-[feature]- [mode]-[option]
Details of the fields are
os: mandatory
possible value: os
please note that this field is needed in order to select parent jobs to list and do blocking relations between them.
[controller]: mandatory
example values: nosdn, ocl, odl, onos
[feature]: mandatory
example values: nofeature, kvm, ovs
[mode]: mandatory
possible values: ha, noha
[option]: optional
used for the scenarios those do not fit into naming scheme.
optional field in the short scenario name should not be included if there is no optional scenario.
Thoughts about necessary fields in such a scheme:
Component-view:
OpenStack (given)
OS-type (CentOS, Ubuntu) for OpenStack controlnodes
SDN Controller
Virtual Switching
MANO Components: there might be different levels depending on the MANO concept: E.g. Tacker vs. Juju, SDNO / NFVO, Service Orcherstrator
Feature view
Typically features influence the set of test case that can be done on the scenario
Typically it should be possible to combine features, e.g. kvm+sfc
Typically it should be possible to have the same features using different components
Typically not all components support all features
Some features require optional additional modules (e.g. Aodh)
Configuration view
Most common example noha / ha
Installer view
Currently not part of the scenario name
* From
17/09/2018

4. Questions Are ovs and kvm components or features?
Relation to artifacts?
Can we achieve one artifact per component?
Do we need features in the scenario name?
17/09/2018

5. Scenario Consolidation: Compatibility Map?
os-nosdn-nofeature-ha
os-nosdn-nofeature-noha
os-nosdn-kvm-ha
os-nosdn-kvm_ovs-ha
os-nosdn-kvm-noha
os-nosdn-kvm_ovs-noha
os-nosdn-ovs-ha
os-nosdn-ovs-noha
os-nosdn-vlan-ha
os-odl_l2-nofeature-ha
os-odl_l2-sfc-noha
os-odl_l2-sfc-ha
os-odl_l2-bgpvpn-ha
os-odl_l2-bgpvpn-noha
os-nosdn-fdio-noha
os-odl_l2-fdio-noha
os-odl_l2-fdio-ha
os-odl_l3-fdio-noha
os-odl_l3-fdio-ha
os-odl_l3-nofeature-ha
os-odl_l3-nofeature-noha
os-odl_l3-vpp-ha
os-ocl-nofeature-ha
os-ocl-nofeature-noha
os-onos-nofeature-ha
os-onos-sfc-ha
os-nosdn-lxd-noha
os-nosdn-lxd-ha
Observations:
Too many fields
There are groups of scenarios which contain each other
Do we need everything in ha+noha?

6. Ideas Some scenarios are needed for development
Simple basic environment for installer verification
Start with noha, add ha later
Start with nofeature, add features later
Customer view wouldn‘t need some scenarios:
noha
scenarios, that are “contained“ by others
Do we need to release “contained“ and noha scenarios?
With CI evolution, can we reduce weekly builds to only the scenarios that will be released?
17/09/2018

7. Reduced Compatibility Map
Reduced to 11 top- level scenarios
Suffient to release just these?
Can we find compatibilities to combine further?
MANO and other Danube features will create more....
os-nosdn-kvm_ovs-ha
os-nosdn-vlan-ha
os-odl_l2-sfc-ha
os-odl_l2-bgpvpn-ha
os-nosdn-fdio-noha
os-odl_l2-fdio-ha
os-odl_l3-fdio-ha
os-odl_l3-vpp-ha
os-ocl-nofeature-ha
os-onos-sfc-ha
os-nosdn-lxd-ha
17/09/2018