Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

Version 1 Current »

Status

 DRAFT

SubmitterTrevor Lovett
Contributors
Proposed ReleaseDublin
JIRA Ticket(s)

VVP-109 - Getting issue details... STATUS


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

ID

VVP-Stand-Alone-1

Title

Heat Author Validation

Description

A Heat Template author creates a set of valid HEAT templates using

Primary Actor

Heat Author

VNF Validation Tool

Preconditions

Heat author has downloaded the appropriate VNF Validation Tool from their operator or ONAP.

Main Success Scenarios

  1. Heat author develops an initial set of Heat template files in accordance with the ONAP Heat Guidelines, and wishes to verify their compliance
  2. Heat author launches the VNF Validation Tool from their local machine
  3. Heat author select the desired validation profile (NOTE: the ONAP version will only support a single ONAP profile, but additional validation profiles can be added by an operator)
  4. (Optional) Heat author selects the desired output format of the template. Three formats will be supported: HTML, Excel, and CSV
  5. Heat author selects the source of the Heat templates on their local machine.  This can be either a zip file containing the Heat templates or a directory containing the templates
  6. Heat author selects Validate in the tool and the validation scripts are executed providing progress information during the execution
  7. Once the VNF Validation Tool completes the execution, a summary is provided (success or failure) and a report can be opened to provide more detail.
  8. The report shows there are no violations and provides the following information:
    1. The date and time of report execution
    2. The validation profile selected
    3. The checksum of the files validated
    4. The version of the tool used for validation
    5. The name of the zip file or directory validated
    6. Confirmation that the template was successfully validated

Exception Scenarios

8a. The report shows there are 1 or more violations, and provides the following information:

  1. The date and time of report execution
  2. The validation profile selected
  3. The checksum of the files validated
  4. The version of the tool used for validation
  5. The name of the zip file or directory validated
  6. Confirmation that the template was successfully validated
  7. For each violation the following details are also provided:
    1. The file or files with the violation. In supported formats a link to the file will be provided
    2. The name/ID of the validation that failed
    3. A detailed error message
    4. The requirement(s) ID and text that were violated.  This will be pulled directly from the JSON export of the VNF Requirements project
    5. (Optional) Suggested resolution steps that may aid in correcting the issue

9. Author debugs the issue, corrects the template, and restarts validation at Step 6.

Post Conditions

Heat author has a set of compliant Heat templates ready for onboarding into SDC, and a report validating they passed

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.

Feaure IDDescriptionStatus
F-1Support Validation of ZIP files

COMPLETE

F-2Support Validation of Directories

COMPLETE

F-3Allow operator-specific validation profiles beyond just standard ONAP validations

COMPLETE

F-4Provide Configurations to Customize Output: Excel Reports

COMPLETE

F-5Provide Configurations to Customize Output: CSV Reports

COMPLETE

F-6Provide Configurations to Customize Output: HTML Reports

COMPLETE

F-7Provide Configurations to Customize Output: Allow user to halt validations when basic failures occur that could flood the report with errors

COMPLETE

F-8Provide Configurations to Customize Output: Control verbosity level

COMPLETE

F-9

Allow user to select if environment file rule violations will be reported.  ECOMP suggests that certain environment file parameters be removed prior to onboarding into SDC.   This allows ECOMP to inject these values and reduces the chance that a test value be injected. This is good as part of final preparation, but during testing with Open Stack this can complicate test spin-ups.  This feature will allow the user to ignore such errors.

DUBLIN

F-10Provide downloadable versions of the tool for target platforms: Windows

COMPLETE

F-11Provide downloadable versions of the tool for target platforms: Mac

DUBLIN

F-12Provide downloadable versions of the tool for target platforms: Linux

DUBLIN

F-13Display reports upon completion of validation

COMPLETE

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.


  • No labels