The following Etherpad will be used to gather inputs from upstream test projects and the Dovetail community:
https://etherpad.opnfv.org/p/Dovetail_Future_Release_Priority_Inputs
In the Nov 28, 2017 TSC meeting, we discussed ways of planning for future releases of the OPNFV Verified Program.. During the Danube cycle, we adopted a pragmatic approach of working from bottom-up (i.e. what the community had already done), but noted its limitations as well as top-down analysis of overall program requirements. The details are documented in this Addendum. Specifically, the Addendum called out areas where either features or test cases fall short in OPNFV release (Danube), and future test area considerations based inputs from the community and EUAG. The following is an attempt to organize the information in a table format with an intent to facilitate community wide discussions, which, hopefully lead to actions to identify where the priorities are, and efforts from all projects to fill those gaps. We invite the whole community to provide feedback, ideas/comments.
Test Area in OPNFV Verified | Danube | Euphrates | Fraser | Gambia |
---|
Basic Cloud Capabilities (defined a single VM, networked, providing simple network functions). See here. | - API testing (2016-08)
- API backward compatibility - yes, same as Openstack, but not yet clearly defined in other areas
- tempest scenario (i.e. small nuggets of use patterns in system level) - included but optional.
- Port security and security groups
- VM life-cycle events
- VM networking
- VM resource scheduling
- Forwarding packets in the data path
- VIM: Openstack only
- SDN: transparent mode only (e.g. ODL can be used as a Neutron plugin)
- Datapath: L3 level readability only - includes vPing, and ping tests on all networking datapath validations.
- VNF: VM for testing/ping.
| - A subset of the tempest scenario tests are commonly used/supported/adopted and we should consider promote them to mandatory.
- Additional test cases
Candidates - Tempest smoke tests: OpenStack API tests
DOVETAIL-599
-
Getting issue details...
STATUS
- SNAPS smoke tests: OpenStack API tests
DOVETAIL-630
-
Getting issue details...
STATUS
| - VIM: k8s test suite (see kubernetes certified.)
- VIM: define how to accommodate VIM choices in dovetail test framework
- Functest's proposed work on k8s
Candidates - Patrole: testing OpenStack RBAC configuration using Tempest
| |
NFV Specific Functional Requirements | - SDNVPN testing included in optional
- IPv6 testing included in optional
- SFC is not included due to upstream lack of maturity, or adoption
- SDN explicit north bound API not included - opnfv has not taken on this level of testing in large scale, upstream status unclear.
| - IPv6 extensions? Candidates - SDNVPN Tempest API tests
DOVETAIL-598
-
Getting issue details...
STATUS
| Candidates | |
HA and resiliency, (VM migration) | - HA included as mandatory tests - supporting Openstack control service HA and resource overloads.
- verify service continuity
- verify control process recovery
- HA extensions needed.
| Candidates - OpenStack controller node HA
DOVETAIL-605
-
Getting issue details...
STATUS
- OpenStack message bus HA
DOVETAIL-605
-
Getting issue details...
STATUS
- OpenStack Virtual Router HA
DOVETAIL-605
-
Getting issue details...
STATUS
| Candidates - OpenStack database HA
YARDSTICK-960
-
Getting issue details...
STATUS
- OpenStack Nova conductor HA
YARDSTICK-959
-
Getting issue details...
STATUS
- OpenStack Nova scheduler HA
YARDSTICK-958
-
Getting issue details...
STATUS
- OpenStack Heat-API HA
YARDSTICK-961
-
Getting issue details...
STATUS
| |
stress testing, platform-in-place-upgrade | - Considered Bottleneck project proposal with a basic set, but it needed more testing experience in the community.
- More comprehensive set yet to be defined.
| Candidates- Bottleneck stress test
DOVETAIL-631
-
Getting issue details...
STATUS
| - Is VM migration having a commonly accepted use pattern?
| |
Security (including security features as well as tools such as vulnerability scanning) | - Security: openstack features included in API and tempest scenario testing
- virtual network isolation,
- security groups,
- port security
- and role based access control
| - Discussing during the plugfest
- Domain expertise and contribution needed
| | |
Service Assurance, also include the tools for SA - platform operational insights, e.g. telemetry, logging
- fault management
| - Not yet
- looking for contributions
- Doctor has a long list of dependencies
| - looking for contributions
| | |
Use Case Testing | - Net yet
- Some VNFs have been worked on in Functest, sampleVNF, discussion planned in plugfest how to proceed
| - Discussing methods to incorporate use case testing
- Functest vIMS (cloudify orchestrated) - dependency to be analyzed, stable/mature?
- alternatively, vIMS with Heat
- other use cases in sampleVNF
- other use cases in ONAP (e.g. vCPE) or other upstream projects
| | |
Performance | | - There will be a info session to discuss during plugfest at Portland
| - Many good tools have been worked on in projects such as vsperf, and others, discussion planned in plugfest on how to address hardware dependency and methodology pitfalls, then decide if or how to proceed
| |
MANO - ONAP - VNF testing (e.g. packaging, on-boarding etc.) | | - There will be an info session to start the discussion in plugfest to think how we can collaborate
| - ONAP just had the first release, related projects: VNFSDK, VVP
- Consider Fraser as a possible integration point
| |
Multi-Site Federation | | | | |
Efficiency, e.g. hardware and energy footprint of the platform | - Net yet
- Interesting area calling for contributions
| | | |
Dovetail tool improvements (together with all testing projects) | | - format result.json in a human readable and json-compliant format
provide test result overview after a test run separation of test suite yaml spec file from the tool, so that the tool framework development/testing and the test suite spec can be cleanly decoupled developer's guide documentation
| - harmonization of log files
- tagging mechanism for test cases from all test projects
- LaaS support - dovetail should become a part of LaaS toolset, can be easily run any time by everyone
| |
Below are some previous inputs from the Design Summit, Beijing Summit and OPNFV Plugfests:
- Inputs collected during the Design Summit dovetail session on June 13
Stress testing
Incorporate more OPNFV feature projects (e.g. SFC etc.)
Include Models (the OPNFV project) test cases (launch a sample multi-VM VNF)
- We need to check these against the test case requirements
Include Doctor (optional/mandatory is tbd)
- EUAG inputs June 15 during the Beijing Summit
- Earlier inputs from Plugfest April 24-28
- discussed the topic of how to potentially do performance testing through opnfv projects in this area
- any area of security testing that may be applicable, e.g. scanning for security vulnerability
(
DOVETAIL-599
-
Getting issue details...
STATUS
)