Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
==== Project Name: ====

  * Proposed name for the project: ''OPNFV Compliance Testing''
  * Proposed name for the repository: ''affirm''
  * Project Category: 
    * Integration & Testing

==== Project description: ====

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.

==== Scope: ====

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.

== Entry level OPNFV Compliance. ==
 
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: 
  * Applications (VNF's) – the VNF can be deployed on an OPNFV/Pharos platform and reach an operational state
  * Hardware – The hardware is able to be configured to Pharos specs and supports the deployment of the platform 
  * Platform – the platform is able to be deployed on an OPNFV Pharos compliant hardware

== OPNFV Compliance. ==

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:
  * Applications (VNF's) – the application can be deployed on any OPNFV/Pharos platform passing functional, security, portability & robustness requirements
  * Hardware – The hardware is able to be configured to Pharos specs and supports the deployment of any OPNFV platform passing functional, security & robustness certification
  * Platform – the platform is able to be deployed on any OPNFV compliant hardware passing rigorous functional, security & robustness tests

== OPNFV Ninja ==

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

  * Describe the problem being solved by project
  * Specify any interface/API specification proposed, 
  * Specify testing and integration:
  * Debugging and Tracing 
  * Unit/Integration Test plans
  * Client tools developed for status shows etc. 
  * Identity a list of features and functionality will be developed.
  * Identify what is in or out of scope. So during the development phase, it helps reduce discussion.
  * Describe how the project is extensible in future

==== Testability: ''(optional, Project Categories: Integration & Testing)'' ====

  * Specify testing and integration like interoperability, scalability, high availablity
  * What QA and test resources will be available?

==== Documentation: ''(optional, Project Categories: Documention)'' ====

  * API Docs
  * Functional block description

==== Dependencies: ====

  * Identify similar projects is underway or being proposed in OPNFV or upstream project
  * Identify any open source upstream projects and release timeline. 
  * Identify any specific development be staged with respect to the upstream project and releases.
  * Are there any external fora or standard development organization dependencies. If possible, list and informative and normative reference specifications.
  * If project is an integration and test, identify hardware dependency.

==== Committers and Contributors: ====

  * Names and affiliations of the committers
  * Names and affiliations of any other contributors

==== Planned deliverables ====

  * Described the project release package as OPNFV or open source upstream projects.
  * If project deliverables have multiple dependencies across other project categories, described linkage of the deliverables.

==== Proposed Release Schedule: ====

  * When is the first release planned?
  * Will this align with the current release cadence


Use the above information to create a key project facts section on your project page
===== Key Project Facts =====

** 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).
Wiki

User Tools

Site Tools

Page Tools
