Project Name: VNF Validation Program (ONAP ICE)  

  • Proposed name for the project: VNF Validation Program (ONAP ICE)
  • Proposed name for the repository: vvp

Project description:

The project is to develop a validation program to provide assurance of VNF interoperability with ONAP. Obtaining a validation shall be a self-service activity and should be against a reference release of ONAP for use by the VNF provider & any other validation authority.

This project at ONAP will not operate as a Validation Authority and will create a process to identify and qualify Validation Authorities. Self-Certification may be considered as a Certification authority option.   

The overall objective of the proposal is to build & foster an active community at ONAP contributing to all aspects of an ONAP VNF Validation program, and the key goals are:  

  1. Define and start to execute on a long-term strategy & goals to support and allow for a resource efficient model for VNF validation across the combined ONAP ecosystem.
  2. Build & foster an active contributor community across the ONAP ecosystem to support a broad alignment & definition around the ONAP VNF requirements & Guidelines.
  3. Introduce an efficient and seamless process to allow the community to contribute to all aspects of the validation process and platform.

It will be important as part of these deliverables to define ways for 3rd parties to carry out the validation to allow for an efficient and broad adaption. The developed processes and tools will be available for any use within the scope of the Apache 2.0 license and all changes must be contributed back the ONAP community.

Exploring possible expansions to the validation scope is an essential part of this project and especially looking to define specific steps to do so. Some immediate candidates would be to validate the integration with DCAE and/or A&AI as well introducing validation of TOSCA templates. This work by its very nature will need to be closely linked to the work with the ONAP VNF Requirements,  VNF Modeling specification and VNF SDK & Tooling.

Key related projects are the VNF SDK & Tooling and VNF Requirements & Guidelines both will play important roles into defining the long-term direction for the program. 

The project is intended to validate the following:

  1. VNF Requirements compliance (primarily VNF on-boarding requirements in the first release)
  2. VNF Operates with ONAP (including e.g. VNF Instantiation, VNF Monitoring)
  3. VNF template specification

This project will also propose how to deal with:

  1. revisions to the validation testing regime,
  2. changes to the VNF, and
  3. changes to the VNF metadata

This project will provide a process to evolve the validation criteria based on experience and as the VNF Requirements & Guidelines evolve. At each release of ONAP, the scope of functionality tested and the test coverage for VNF validation may change. Lessons learned from operational experience may generate additional VNF requirements, or lead to improved test coverage etc.

The VNF Provider is expected to maintain its VNFs resulting in multiple versions including revisions dues to metadata changes. This Project shall provide guidance as to when revalidation is recommended.  

This Project will validate the VNF package integrity and provenance e.g. using signing & attestation. The exact process will be determined during the project.

This Project will validate VNF operation on some defined infrastructure (cloud) resources & environment. These tests can also include verification of the VNF compatibility with specific NVFI envs, e.g. public/private clouds and SP-specific NFVI deployments or standard reference NFVI platforms such as developed by OPNFV centered upon major commercial OpenStack distributions. The scope of such testing will be determined during the project.

This Project will maintain the authoritative set of tests and test procedures for Validations of VNFs. This project shall develop the tests and test procedures traceable to the VNF Requirements & Guidelines.

This Project shall report the test coverage of the VNF Certification program against the VNF Requirements and the ONAP. Each VNF requirement should be checked via a test to enable automation 'certification".

The Project shall report the results of the validation test suite on a given VNF to the person invoking the validation test.

The VNF Validation testing shall be as automated as possible. This Project shall develop that automation framework for validation testing.


The scope for this project is to establish an ONAP VNF Validation Program by the end of 2017 allowing anyone to obtain an ONAP Compatible label for their VNFs. The key deliverables currently identified for this project to be completed by the end of 2017 are:

  1. Define & establish an overall governance model for the program to properly continuously define a scalable, and flexible model for validating
  2. Define & establish a resource-efficient model for VNF providers and other parties to acquire an ONAP Compatible label.
  3. Define a roadmap for the expansion of the program to include additional validation scope and dependencies to other projects inside ONAP

Note: The focus for the OpenStack base

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?
    • The VNF Validation Program will utilize the architecture to validate VNFs against it.
  • What other ONAP projects does this project depend on?
    • This project depends on SDC, VNF Validation Program, and VNF Requirements
  • How does this align with external standards/specifications?
  • Are there dependencies with other open source projects?
    • OpenStack

ONAP VVP Governance-Nov 9-2017.pptx


  • Primary Contact Person: Erik Sundelof 
  • Names, gerrit IDs, and company affiliations of the committers
  • Names and affiliations of any other contributors
    • Parviz Yegani, Huawei
    • Paul McGoldrick, AT&T
    • Michael Lamb, AT&T
    • Yotam Avivi, AT&T
    • Almog Laktivi, AT&T
    • Areli Fuss, AT&T
    • Ruslan Gafiulin, AT&T
    • Tomer Cohen, AT&T
    • Amir Skalka, AT&T
    • Madhavi Krishnan, TechMahindra
    • Eric Debeau, Orange
    • Stephen Gooch, Wind River
    • Andrei Kojukhov,, Amdocs
    • Trevor Cooper, Intel
    • Amie Levy
    • Chengli Wang, China Mobile
    • Helen Chen, Huawei
    • Gary Wu, Huawei
    • Zygmunt Lozinski, IBM
    • Don Levy, AT&T
    • Amy Zwarico, AT&T
    • Maopeng Zhang, ZTE
    • Hui Deng, Huawei
    • Michael Brenner, Cloudify
    • Moshe Hoadley, Amdocs
  • Project Roles (include RACI chart, if applicable)

Other Information:

  • link to seed code (if applicable)
  • Vendor Neutral
  • if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
  • Meets Board policy (including IPR)

Use the above information to create a key project facts section on your project page

Key Project Facts

Project Name:

  • JIRA project name: vvp
  • JIRA project prefix: vvp

Repo name: 

  • org.onap.vvp/devkit <deprecated and locked in the Dublin release>
  • org.onap.vvp/ansible-ice-bootstrap <deprecated and locked in the Dublin release>
  • org.onap.vvp/portal <deprecated and locked in the Dublin release>
  • org.onap.vvp/engagementmgr <deprecated and locked in the Dublin release>
  • org.onap.vvp/cms <deprecated and locked in the Dublin release>
  • org.onap.vvp/jenkins <deprecated and locked in the Dublin release>
  • org.onap.vvp/haproxy <deprecated and locked in the Dublin release>
  • org.onap.vvp/postgresql <deprecated and locked in the Dublin release>
  • org.onap.vvp/gitlab <deprecated and locked in the Dublin release>
  • org.onap.vvp/jeeves <deprecated and locked in the Dublin release>
  • org.onap.vvp/test-engine <deprecated and locked in the Dublin release>
  • org.onap.vvp/validation-scripts
  • org.onap.vvp/documentation
  • org.onap.vvp/image-scanner  <deprecated and locked in the Dublin release>
  • org.onap.vvp/regression-tests <added in Dublin release>

Lifecycle State: incubation
Primary Contact: Steven Wright
Project Lead: Steven Wright
mailing list tag #vvp

*Link to TSC approval: 
Link to approval of additional submitters: 

  • No labels


  1. A few comments on this proposal:

    1. This project proposal template is not fully populated; key information is missing and there are formatting issues throughout.
    2. Certification implies a high level of interoperability testing and a certificate issuing authority.  Do we want this level of testing?  Or is the goal more around Compliance testing against a specific ONAP Release(s)?
    3. How is this project dependent upon the VNF SDK project? Is there overlap?
    4. Should the project proposal use normative keywords (e.g., SHALL, WILL, etc.)? If so, we should be consistent on what set of Normative Keywords ONAP will use and their definitions/meanings.
    5. Regarding this following statement

    This Project WILL validate VNF operation on some defined infrastructure (cloud) resources & environment.

    Will this project define and specify the Physical and/or Virtual infrastructure and environment in which the VNF will be tested for ONAP Compliance?

  2. what's the project's scope and what could be included in release 1?

    1. Wenyao: The project should now be updated with a clearer scope.

      1. Thank you for your updating.

        But could the overall governance model and resource-efficient model in the scope be more detailed? It seems high level and abstract to me (and others?).

  3. In order to have unified modeling in the ONAP, it would better that ICE project depends on modeling project for example, service component modeling, VNF modeling,  policy modeling workflow modeling, Parsers et al.

  4. Does this project depend on the code base of AT&T's ICE? According to LightReading, AT&T's ICE will become open source in mid 2017, any further update on this such as specific dates?

    LightReading article on ICE to become open source in mid 2017:

    1. there was some discussion of dates in the presentation at the May members meeting available online here.

      1. Thanks for the quick reply. The doc includes release schedules in Table 1 and Table 2. Some of the items were planned to be released on May 17. Are we on schedule or it's been adjusted? Thanks.

        1. We are on track for the delivery schedule. We have held off on the release as we get the repos setup yet the code is ready to be released per as the schedule outlined in the document.

    2. Kang: It will initially be based on the work inside AT&T ICE, yet the release of ICE will be via ONAP so it is not a dependency.

  5. One question about VNF Validation Program (ICE) which confused me is whether ICE including any tools to perform validation (according to the project description) or just define and establish models (according the the scope)? If ICE also tooling like VNF SDK, then what is the relationship between these two projects?

    1. ICE includes extensive tools to validate VNFs per as the ONAP guidelines especially around HEAT. These will be leveraged initially and then any relevant tools developed inside the VNF SDK & Tooling will be leveraged.

  6. The second sentence in second paragraph  "This project will create a process to identify and qualify Validation Authorities will be developed and maintained" looks weird to me. Looks like some words are missing? If not could you clarify the sentence?

    1. Corrected the sentence.

  7. Could it be possible to add links toward the 2 cross-dependent project VNF Requirementa and VNF SDK? That will help to understand how everything is connected.

    1. Added inline references to the two projects.

  8. The last sentence of the project description mentions "The VNF Validation testing shall be as automated as possible. This Project shall develop that automation framework for validation testing." Could you elaborate on how the automation framework developed by this project (VNF Validation program) is different from the tooling developed by the VNF SDK project?

    1. They are related. initially it will likely primarily leverage the existing capabilities of ICE with some additions from the VNF SDK & Tooling project, yet long-term it will converge with the various relevant tool suites. The VNF SDK & Tooling is therefore a related project. 

      1. ok thanks. Glad we are not re-inventing the wheel.

        1. Yep. The breakdown into three projects was done in collaboration with the VNF Requirements and VNF SDK & Tooling team to make sure we have a good understanding of the overlaps and how to manage them. The existing code bases from ICE will likely be contributed into the VNF SDK Tooling project as well.

  9. Is the intention to move all of the legacy AT&T ICE code into the VNF SDK project?  Or will the VNF Validation Program project maintain some subset of AT&T ICE code as an ongoing deliverable?

    1. The exact split of code will be determined as the projects proceed. Right now the majority of the code will go into the VNF Validation Program.

    1. According to the project description and scope, it looks like that this project does not validate VNF directly but define and establish some models. Is that right? But why there is a long list of repo names?

    2. "This Project will maintain the authoritative set of tests and test procedures for Validations of VNFs. This project shall develop the tests and test procedures traceable to the VNF Requirements & Guidelines.", does tests mean test cases? what is the relationship between the test cases created by VNF Requirements and this projects?
    1. There is a need for a handoff between the VNF Requirements work and the VNF Validation work. The specific format of that handoff will need to be decided by the two groups. In general the VNF Requirements  project is  dealing with non executable text,  but needs to refine that from general guidelines to more specific test case descriptions.  

      1. The validation program requires a tracking model including validation mechanisms which is what the repos are for.
      2. Test cases are in many ways interchangeable with tests. Any test is based on the at the time current requirements. 
  10. Does this project include the validation of  the VNF related to the 3rd VNFM ?

  11. Did this project start its activity? I did not see any meeting in ONAP calendar.

    1. Regular project calls are starting August 31st. 

      1. Tks. and who is the PTL?

        1. I'm acting as PTL in Erik's absence

  12. When will the existing AT&T ICE code be open sourced?  Right now the vvp repos are still empty.

  13. Hi Paul/Erik - attempting to install VVP devkit on linux machine. I am following instructions in file, in devkit folder (recently released VVP seed code). Installed dnsmasq, matchbox. Executed ". setenv" and it works fine. After "vagrant up", i am getting below error: There was an error loading a Vagrantfile. The file being loaded
    and the error message are shown below. This is usually caused by
    a syntax error.

    Path: /home/sandeepos/VVP-Development/devkit/vagrant/pxe/Vagrantfile
    Line number: 45
    Message: NameError: uninitialized constant YAML

    WOuld appreciate any insights, specifically for uninitialized constant YAML? Thanks

    1. I encountered same issue . Just add require 'yaml' as first line of Vagarantfile

      1. If this fix is confirmed how about you guys commit it for review?

  14. Hi Viswanath - did you get VVP fully deployed and working? Thanks

  15. Guys, Going through your project - in the context of bringing up vvp in Kubernetes - over the next week or two