Stand-alone VVP Tool

This tool has been accepted and contributed to the Dublin release of VVP.

Abstract

The core component of the VNF Validation Program (VVP) are 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 multi-container, web platform that can both execute and manage the engagement of VNF HEAT validation

While both models have their use cases, they both require a level of technical proficiency or infrastructure requirements that may stand as a barrier to entry.  The aim of this proposal is to ensure that the core validation-scripts remain usable in a variety of context by remaining modular and supporting command-line execution, but also providing a stand-alone wrapper that will allow users to execute the scripts in a native GUI on their machine.  

This will both simplify the execution of the validation scripts, and also allow the validation to be decentralized and detached from a central web portal.  This is extremely helpful to a Template author as they can receive feedback quickly and iteratively during the authoring of the templates.

Rationale/Goals

• Allow users of Windows, Mac, and Linux operating systems to be able to download and run a simple application to validate their HEAT templates and review meaningful reports on any validations.
• Ensure that all reported failures cleanly describe the errors and denote the requirement(s) that have been violated.
  • NOTE: Some of this work on improving reporting and mapping validations to requirements was done in Casablanca.  This work will be leveraged and possibly extended in Dublin.
• For the supported execution environments, users should not be required to install additional dependencies to run the application (all dependencies should be packaged).
• Increasing the ability for template authors to self-serve during template creation:
  • Reduce reliance on a central hosting solution to ensure HEAT authors can iteratively develop their templates locally with a fast feedback loop.
  • Reduce operator support for HEAT compliance by enabling easy validation in the VNF provider environment prior to submission.
• Ensure that the core validation-scripts remain modular and independent of the application.  The implementation of the app 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

Other Options Considered

• VVP already has a web application, but it is a complicated application and in many instances has more features and capabilities than required.  Additionally, it can not easily take advantage of enhancements to the validation scripts such as the improved reports or mapping of requirements to validations.  The VVP core team still feels there are valid use cases for a web portal, but the current implementation will likely be deprecated.  A more tightly-focused web portal would likely still be useful, and complementary to stand-alone execution. While we are proposing a stand-alone model for execution for the rationale stated above, we do feel there are use cases where a centralized portal could prove complementary.

Use Cases

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 initial 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.

Screenshots

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

GUI

Report - Success (HTML)

Report - Failures (HTML)

Technologies

The VVP validation scripts are written in Python so the desire is to continue to leverage Python to the greatest extent possible.  Per the goals, we desire that the GUI can be executed in a large number of environments and operating systems while not maintaining a number of native versions of the application.  To acheive this, the application will be written use the Tk GUI support built-in to Python.  Applications written with Python's Tk bindings can be run on any platform that supports Python, and that will cover our desired deployment targets.

We also wish to provide stand-alone downloadable bundles for a set of target platforms.  These bundles should not have any dependency on a Python installation on the users machine.  Instead we will leverage PyInstaller to build the distributable versions of the application.  A version of the distributable can already be generated for Windows as part of the seed code, and we would like to extend that to Mac and Linux as part of the Dublin release.  The one item that is challenging is that the distributable must be built on the target platform which will likely limit some of our CI/CD options for building the distributable as we do not have Windows and Mac machines to build the distributables in the CI/CD environment.

As noted before, the goal is for the validation-scripts to remain modular and usable in a wide-variety of scenarios.  As such, we seek to limit the logic put into the GUI code to the greatest extent possible.  Enhancements to reports, profile selection, and other settings are all added to the validation-scripts as command line parameters and the GUI simply provides an easy way to configure and view the execution of the command-line scripts.