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:
http://artifacts.opnfv.org/octopus/docs/scenario-lifecycle/index.html
Also a first draft of the template for SDF (Scenario Descriptor File) is available and in review: https://gerrit.opnfv.org/gerrit/#/c/30677.
Review comments to the SDF have not yet been updated to the lifecycle document.
| Scenario | Installers | Owners | Required by = Owner for features | Installer- support (Installer / Person) | Test Owner | Remarks and Ideas for roadmap |
|---|---|---|---|---|---|---|
| k8-nosdn-baremetal-core | JOID | JOID: Artur Tyloch | ||||
| k8-nosdn-baremetal-lb | JOID | JOID: Artur Tyloch | ||||
| k8-nosdn-os-lb | JOID | JOID: Artur Tyloch | ||||
| os-nosdn-dpdk_ipv6 | JOID ha&noha | JOID: Artur Tyloch | IPv6? | No, this scenario has nothing to do with IPv6 Project | ||
| os-nosdn-fdio-ha | Apex | Apex: Frank Brockners | ||||
| os-nosdn-kvm_ovs_dpdk | Fuel ha&noha, | Fuel: Raghuveer Reddy, | ||||
| os-nosdn-kvm_ovs | Fuel ha&noha, | Fuel: Raghuveer Reddy, | ||||
| os-nosdn-lxd | JOID ha&noha | JOID: Artur Tyloch | ||||
| os-nosdn-nofeature-ha | Apex 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-ha | Apex | Apex: Thomas F Herbert | ||||
| os-ocl-nofeature-ha | JOID ha&noha | JOID: Artur Tyloch | ||||
| os-odl_l2-bgpvpn-ha | Apex, Fuel | Apex: Tim Irnich, Fuel: Tim Irnich | ||||
| os-odl_l2-fdio-ha | Apex, Fuel | Apex: Frank Brockners, Fuel: Fedor Zhadaev | ||||
| os-odl_l2-moon-ha | Compass | Compass: Ruan HE | moon/ Ruan HE | ownership already with non-installer person | ||
| os-odl_l2-nofeature-ha | JOID ha&noha, Fuel ha&noha, Compass ha | JOID: Artur Tyloch, Fuel: Fedor Zhadaev, Compass: Justin chi |
| |||
| os-odl_l2-sfc-fdio-ha | Apex, Fuel | Apex: Brady Johnson, Fuel: Brady Johnson | ||||
| os-odl_l2-sfc-ha | Apex ha&noha, Fuelha&noha, Compass ha | Apex: Brady Johnson, Fuel: Brady Johnson, Compass: Justin chi | SFC? | |||
| os-odl_l3-fdio-ha | Apex, Fuel | Apex: Frank Brockners, Fuel: Fedor Zhadaev | ||||
| os-odl_l3-gluon-noha | Apex | Apex: Georg Kunz | NetReady / Georg Kunz |
| ||
| os-odl_l3-nofeature-ha | Apex ha, Fuel ha&noha, Compass ha | Apex: Tim Rozet, Fuel: Fedor Zhadaev, Compass: Justin chi | ||||
| os-odl_l3-ovs-noha | Apex | Apex: Thomas F Herbert | OVSNFV? | |||
| os-odl-ovs-ha | Apex | Apex: Thomas F Herbert | OVSNFV? | Question: should this be named os-odl-l3-ovs-ha (radez) No, I think the _l3 will go away because it's default now. | ||
| os-onos-nofeature-ha | Apex, JOID, Compass | Apex: Tim Rozet, JOID: Artur Tyloch, Compass: Justin chi | ONOSFW | Basic ONOS scenario | ||
| os-onos-sfc-ha | JOID, Compass | JOID: Artur Tyloch, Compass: Justin chi | ONOSFW | Parent: os-onos-nofeature-ha Goal: Create generic scenario for ONOS | ||
| os-ovn-nofeature-ha | Apex | Apex: Tim Rozet | OVN4NFV? |
2 Comments
Steven Wright
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
Ulrich Kleber
Thanks.
We moved to review the scenario lifecycle in document format. You could look at the patch creating the document at
https://gerrit.opnfv.org/gerrit/#/c/28443 or the generated html at http://artifacts.opnfv.org/octopus/review/28443/scenario-lifecycle/index.html .
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.