Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

Version 1 Next »

Status

 DRAFT

SubmitterVincent Scharf
Contributors

Vincent Scharf

Proposed ReleaseDublin
JIRA Ticket(s)

VVP-121 - Getting issue details... STATUS


Abstract


The core component of the VNF Validation Program (VVP) is the validation scripts that verify that a set of HEAT templates adhere to the ONAP requirements specified in the VNF Requirement's HEAT section.  As of the Casablanca release, there are two methods for executing the validation scripts provided with VVP:

  • Execute via the command-line (including setting up the necessary Python environment and dependencies)
  • Deploy a huge multi-container, web platform that can both execute and manage the engagement of VNF HEAT validation

While executing the validation scripts from the command line is helpful when it comes to developing VNFs for ONAP, especially if you are working in larger teams, having tools locally on your own machine is not ideal, because no one else has direct access to your toolchain. Taking into consideration, that the current web platform is gonna get deprecated due to its size and complexity, there will be no way to directly map the changes done to the source code to the test results, which makes it harder to find bugs quickly. Also, there is most likely always management involved in the development process, especially when it comes to actual business. There will be no way of tracking the progress of a VNF development process at a high level. The VVP-web approach should address this gaps.

Although there is a lot of functionality involved with this approach, the final product should be a one-click deployment with minimal needs in terms of resources and infrastructure.

After seeing a demo of the Stand-alone VVP Tool I added some additional proposals on the reports that are getting generated by the application.

Rationale/Goals

  • Allow users to deploy a web-based validation platform with one click.
  • Provide a version-controlled validation with history and reports on the status of the VNF.
  • Enable users to validate HEAT templates that are not under git by simply uploading them as a ZIP file.
  • Allow non-technical users to get an overview of the VNF development process by using a measurement feature.
  • Ensure that the core validation-scripts remain modular and independent of the application. The implementation of the web platform should not impact the scripts being used in other scenarios such as a web app, docker container, etc.
  • Allow Operators/Service Providers to extend and execute additional validations based on their specific needs and ONAP implementations.
  • Ensure the application is portable across a wide range of operating systems and environments by proving it as a container based environment.


Use Cases

ID

VVP-Web-1

Title

Simple Heat validation

Description

A user wants to validate a set of HEAT templates

Primary Actor

User

Preconditions

VVP-web is set up on a server accessible from the user's workstation.

Main Success Scenarios

  1. The user accesses the web page
  2. The user uploads the HEAT template to the server
  3. The server runs the validation scripts in the background
  4. The server prompts the user with a results page that concludes all test runs

Exception Scenarios

4. The report lists all passed and failed tests and provides the following additional details for the violations:

    1. The file or files with the violation. A link to the file.
    2. The name/ID of the validation that failed
    3. A detailed error message
    4. (Proposal) The requirement(s) ID and text that was violated. This will be pulled directly from the JSON export of the VNF Requirements project
    5. (Proposal) Suggested resolution steps that may aid in correcting the issue

Post Conditions

The user gets a report that shows the current state of the VNF regarding the fulfilment of the ONAP requirements.

ID

VVP-Web-2

Title

VNF project 1

Description

A team from a VNF provider develops a VNF for an operator

Primary Actor

Developer

Preconditions

VVP-web is set up on a server accessible from all team members local workstations.

Main Success Scenarios

  1. The developer changes some code.
  2. The developer pushes the code to the vvp-web server.
  3. The server registers that new code got pushed.
  4. The server runs the vvp-validation-scripts in the background
  5. The developer goes to the project overview page.
  6. The developer clicks on the latest run which is referenced by the commit ID it is linked to
  7. The developer accesses the validation report
  8. The developer sees all tests passed. No further action needed.

Exception Scenarios

  1. The developer changes some code.
  2. The developer pushes the code to the vvp-web server.
  3. The server registers that new code got pushed.
  4. The server runs the vvp-validation-scripts in the background
  5. The developer goes to the project overview page.
  6. The developer clicks on the latest run which is referenced by the commit ID it is linked to
  7. The developer accesses the validation report
  8. The report contains failed tests and provides the following additional details for the violations:
    1. The file or files with the violation. A link to the file.
    2. The name/ID of the validation that failed
    3. A detailed error message
    4. (Proposal) The requirement(s) ID and text that was violated. This will be pulled directly from the JSON export of the VNF Requirements project
    5. (Proposal) Suggested resolution steps that may aid in correcting the issue
  9. The developer analyses the violations
  10. The developer fixes the violations
  11. Starts again at 2.

Post Conditions

The developer developed a fully ONAP compliant VNF.

ID

VVP-Web-3

Title

VNF project 2

Description

A team from a VNF provider develops a VNF for an operator

Primary Actor

Project Manager

Preconditions

VVP-web is set up on a server accessible from all team members local workstations.

Main Success Scenarios

  1. The project manager wants to determine the progress of the project.
  2. The project manager navigates to the project overview page
  3. The project manager looks at the graph at the very top of the page, showing the number of tests failed, skipped and passed over time/commits

Exception Scenarios


Post Conditions

The project manager has an overview of how the development is progressing.


Features

A set of seed code has been developed that addresses the majority of features and use cases described.  As part of the community process, all aspects can be reviewed and evolved.  The following table summarizes the initially proposed features for Dublin and their current status. Some items are addressed as part of the seed code while others will be addressed in Dublin if the proposal is accepted.

FeaureIDDescriptionStatus
F-1Support Validation of ZIP files

COMPLETE

F-2Support Validation of Git repositories

COMPLETE

F-3Provide results page which concludes the validation

COMPLETE

F-4Provide repository overview page, which provides a history on all ever done changes and validation runs for the Git repository

COMPLETE

F-5

Implement GitWeb to allow users to check the changes done to the VNF in a given commit associated with a validation run

COMPLETE

F-6Provide a repository analytics graph to track progress

COMPLETE

F-7Extend the reports the application generates by the features provided in the Stand-alone VVP Tool 

DUBLIN

F-8Brand the web application according to the ONAP standards

DUBLIN

F-9Allow users to link their own Git instance instead of using the built-in one (e.g. company GitLab etc.)

DUBLIN

F-10Extended analytics capabilities for the repository summary page

DUBLIN

F-11(Proposal) User management?

PROPOSAL


Screenshots

The following screenshots are based on the seed code implementation, and subject to further review, feedback, and updates.


Simple HEAT validation





Git repository





  • No labels