Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


TitleDomainProblem addressedDescriptionLinks
CI EvolutionInfra
  • Inconsistency in how things are done for different installers/scenarios
  • Inconsistency on resource management towards the installers/waste of CI resources
  • Different level of code quality on master for different installer/scenarios due to not having patch verificaiton
  • Long duration/enhanced test cases not run in Colorado

CI Evolution description has been initiated in Brahmaputra.

The complete description can be found in CI Evolution

Phase 1 and 2 aimed to be implemented for Danube.

CI Evolution
description file
  • POD description file - define hardware resources in a POD
This effort provides a common configuration file for installer and test projects to useInfra WG Discussions
Pharos DashboardInfra
  • plan is to get at least one lab supported by the tool
a tool for community to request hardware resources in Pharos labsPharos Dashboard
Scenario consolidation Infra
  • Too many scenarios, and the number of scenarios can only increase

Proposal to reduce the number of scenarios in a release 

(Ulrich Kleber)
Slide deck Scenario Considerations
Test consolidationTest
  • Very hard to know the available test cases across the different test and feature projects
  • Difficult without diving in each project to know what can be used or not
  • Wheels reinvented in terms of tooling / framework
  • Only Functest and Yardstick considered for release criteria
  • Test results/figures not always easy to understand

Creation of a testing landing page allowing any test project to expose test cases and associated constraints

Automatic creation of a catalog based on Testing Database

Qtip Re-scoping to address results post-processing and benchmarkingResult consolidation

Introduction of Stress testsTestLots of tests are run including qualification tests. Frameworks (Yardstick, Rally,..) are available but no stress tests run towards the System Under TestIntroduction of first load/stress tests

DocumentationDocumentationDocumentation too segmented per project. it is very hard for a new user to know where to start. And even umbrella documents per domain (installation, infrastructure, feature, testing) is not very consistent.An effort should be done on documentation. For each release all the projects created their own documentation (user guide, release note, installation guide,..). For a new user it is not easy to read everything and get a global overview. For instance there is no global "Installation" or "Testing" documentation. An effort should be made in Danube to provide more "generic" documentation. This would be helpful in identifying features, test cases without having to dive into each project documentation


MANO Integration pilot
Integration Pilot
MANO stack Integration pilot in Danube requires identifying ways and means to enable MANO modules to integrate with OPNFV VIMAn effort is made in Danube to add nfvo and vnf artifacts through upstream OPEN-O and OpenBaton and Juju over OPNFV VIM  and test sample vnf(vIMS) through functest  This can be cleaned for  consistency across different stacks in future releases


Test cases recommandation for the complianceTest and dovetailin order to show the value of the OPNFV, the test gourp can help to recommande the test cases for the OPNFV compliancetest cases in the compliance set will be important for the OPNFV and will cover the test cases in the test projects and features projects.Dovetail Test Areas and Test Cases