Status | DRAFT |
---|---|
Submitter | Trevor Lovett |
Contributors | |
Proposed Release | Dublin |
JIRA Ticket(s) |
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 |
|
Exception Scenarios | 8a. The report shows there are 1 or more violations, and provides the following information:
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 ID | Description | Status |
---|---|---|
F-1 | Support Validation of ZIP files | COMPLETE |
F-2 | Support Validation of Directories | COMPLETE |
F-3 | Allow operator-specific validation profiles beyond just standard ONAP validations | COMPLETE |
F-4 | Provide Configurations to Customize Output: Excel Reports | COMPLETE |
F-5 | Provide Configurations to Customize Output: CSV Reports | COMPLETE |
F-6 | Provide Configurations to Customize Output: HTML Reports | COMPLETE |
F-7 | Provide Configurations to Customize Output: Allow user to halt validations when basic failures occur that could flood the report with errors | COMPLETE |
F-8 | Provide 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-10 | Provide downloadable versions of the tool for target platforms: Windows | COMPLETE |
F-11 | Provide downloadable versions of the tool for target platforms: Mac | DUBLIN |
F-12 | Provide downloadable versions of the tool for target platforms: Linux | DUBLIN |
F-13 | Display 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.