This is an old revision of the document!
OPNFV Compliance Testing
affirm
The OPNFV compliance testing project (affirm) intends to define and provide a set of OPNFV related validation criteria for levels of OPNFV compliance that will provide for the evaluation of the use of OPNFV trademarks.
The project will incrementally define qualifications for compliance that establish the foundations of how we are able to measure the ability to run the OPNFV platform, how the platform itself should behave, and how applications may be deployed on the platform.
The project intends to implement three levels of compliance that provide a measure of alignment with the OPNFV project for hardware, NFV platform, and NFV applications. This compliance activities are not intended to be exclusive in nature, but are intended to provide a measure for the community on the maturity and capability of OPNFV related offerings.
The entry level for OPNFV compliance is intended to be a set of evaluations that should provide a set of non-exclusive test cases providing a method of identifying the adherence of NFV solutions to the OPNFV projects activities and goals. This can include compliance testing, by execution of a basic set of mandatory test cases, of:
The compliance level is intended to be more challenging to achieve, this should focus on a variety of test cases that demonstrae the expected behaviours and characteristics of an OPNFV based solution. This may be implemented as:
The proposed highest level of compliance achieved here. We’re not only talking about passing tests we are talking about passing benchmarks etc… Application validation – the application can be deployed automatically on any OPNFV/Pharos platform passing functional, security, “performance”, robustness, portability, scalability & stability requirements Hardware validation – The hardware is able to be configured to Pharos specs and supports the deployment of any OPNFV platform passing functional, security, performance & benchmarking certification Platform validation – the platform is able to be automatically deployed on any OPNFV compliant hardware passing rigorous functional, security, performance, benchmarking, robustness & API certification
Use the above information to create a key project facts section on your project page
Project Name: Project Name (repo name)
Repo name:
Project Category:
Lifecycle State:
Primary Contact:
Project Lead:
Jira Project Name: Same as Project name
Jira Project Prefix: [10 Characters max [A-Z] ]
mailing list tag [Should match Jira Project Prefix]
Committers:
foo@bar.com
baz@qux.com
Link to TSC approval: Example http://meetbot.opnfv.org/meetings/opnfv-meeting/2015/opnfv-meeting.2015-03-03-15.01.html
Link to approval of additional submitters: Example http://meetbot.opnfv.org/meetings/opnfv-meeting/2015/opnfv-meeting.2015-03-03-15.01.html
My top of mind thinking goes something like this:
This may be difficult to envision. But I see the need to define and develop each level as we go improving each but maintaining a set of target capabilities to be evaluated (which may evolve over time).