Purpose

This template is to be used for the “Parallel Deep Dive Sessions to Align with architecture / Use cases” at the may ONAP developers event

Instructions.

The purpose of each section is to translate the use cases and functional architecture into specific identified needs for the components, and to identify potential projects to be proposed.  There are three parts to this exercise:

  1. Identify needs based on the use case and architecture on this module, and potential dependencies on other modules or external artifacts.
  2. Group these into projects.  Consider that coding, documentation, and testing is required.   Include an initial scope for the project.
  3. If time, mapping the needs into the projects.

The need identification table has the following columns

-          Identified need: <slogan for the identified need>

-          Brief need description: <a few sentences describing the need>

-          Driver:<Related use case or architecture change, if any>

-          Dependencies:<identify dependencies on other modules or artifacts (e.g. other onap module, models, …)

-          Project: <If time, after the projects are identified, suggest in which project the need would best fit>

Time keeping suggestion:  The exercise time is 45 minutes.  A good practice would be to split into 20 minutes on need identification and 20 minutes on project proposals.

Exercise output.

ONAP Meeting Session name: <insert onap module name>

Need Identification:

Identified Need

Description

Driver

Dependencies

Project fit
(if time)

certification of  VNF interoperability with ONAP

Self Service - Driven by VNF Provider - reference release of ONAP for use by the VNF provider & certification authority

 Who certifies? (not ONAP)

what is certified?

  • VNF Guidelines/ Requirements compliance
  • VNF Operation with ONAP

propose how to deal with both (1) revisions to the certification testing regime and (2) changes to the VNF and (3) changes to the VNF metadata

packaging signing & Attestation

VNF operation on some infrastructure (cloud) resources & enviornment

evolution of the certification criteria based on experience


De-risk deployments

separate Common industry certification from operator specific, or function specific   

Not providing certification of the functions a VNF is to provide

just get started

 Release 1?

(Certification scope may evolve by release)

VNF Requirements available

VNF test cases available

OPNFV

OpenStack?


 1
     
     


Project proposals.

[repeat for each project.  Note: This is not a complete project proposal skeleton, only sufficient enough for this discussion]

Project 1:

Project Name:

-          Provide a brief project name.

Project Description

-          Provide a high level description of the project

Scope:

-          Quickly identify scope, consider: documentation, APIs, models, testing, integration, functionality.

-          Note of any particular deliverables to highlight.

-          If anything is out of scope, not it down

Other:

-          Identify baseline code (if any)

Project 2:

Project Name:

-          Provide a brief project name.

Project Description

-          Provide a high level description of the project

Scope:

-          Quickly identify scope, consider: documentation, APIs, models, testing, integration, functionality.

-          Note of any particular deliverables to highlight.

-          If anything is out of scope, not it down

Other:

-          Identify baseline code (if any)


  • No labels

2 Comments

  1. Each VNF guideline should be checked via a test to enable automation 'certification"

  2. Reference VNFs will be used to test the platform for its behaviors. The test env that results will be able to identify when some requirement is not complied to (e.g. thru error detection tests). We can then use that capability to assess when real VNFs are non-compliant e.g. per package content, APIs, or other dynamic behavioral expectations.

    These tests can also include verification of the VNF compatibility with specific NVFI envs, e.g. public/private clouds and SP-specific NFVI deployments e.g. AIC, or standard reference NFVI platforms such as developed by OPNFV centered upon major commercial OpenStack distributions.