VNFSDK Documentation

VNF SDK APIs

Market Place API

Upload/Re-upload VNF Package

Interface Definition	Description
URI	/onapapi/marketplace/v1/csars
Operation Type	POST
Content-Type	multipart/form-data

Request Parameters:

Attribute	Qualifier	Cardinality	Content	Description
file	M	1	InputStream	The CSAR file stream
file	M	1	FormDataContentDisposition	The detail of CSAR file

FormDataContentDisposition

Attribute	Content	Description
type	String	the disposition type. will be “form-data”
name	String	the control name
fileName	String	the file name
creationDate	Date	the creation date
modificationDate	Date	the modification date
readDate	Date	the read date
size	String	the size
parameters	Map<String,String>	the parameters

Response:

Attribute	Qualifier	Cardinality	Content	Description
csarId	M	1	String	The CSAR identifier is a unique identifier generated by the Market place

Delete VNF package by csarId

Interface Definition	Description
URI	/onapapi/marketplace/v1/csars/{csarId}
Operation Type	DELETE

Request Parameters:

Attribute	Qualifier	Cardinality	Content	Description
csarId	M	1	String	The id of CSAR package

Response:

HTTP Success or Error Code

Download VNF package files

Interface Definition	Description
URI	/onapapi/marketplace/v1/csars/{csarId}/files
Operation Type	GET

Request Parameters:

Attribute	Qualifier	Cardinality	Content	Description
csarId	M	1	String	The id of CSAR

Sample:

/onapapi/marketplace/v1/csars/78ede6f3-66cc-46ab-b748-38a6c010d272/files?

Response:

CSAR Package

Query VNF package information by csarId

Interface Definition	Description
URI	/onapapi/marketplace/v1/csars/{csarId}
Operation Type	GET

Request Parameters:

Attribute	Qualifier	Cardinality	Content	Description
csarId	M	1	String	The id of CSAR package

Response:

PackageMetaData

Attribute	Qualifier	Cardinality	Content	Description
csarId	M	1	String	The id of CSAR package
name	M	1	String	Name of package
provider	M	1	String	Provider company name
version	M	1	String	version of the package
createTime	M	1	String	create time of package
modifyTime	M	1	String	modify time of package
downloadUri	M	1	String	download uri
size	M	1	String	size of the package
downloadCount	M	1	Integer	Number of times the package is download from marketplace
shortdesc	M	1	String	Short description
details	M	1	String	Detailed description

Sample:

{
   "csarId":"78ede6f3-66cc-46ab-b748-38a6c010d272",
   "name":"NanocellGateway",
   "provider":"XYZ",
   "version":"V1.0",
   "createTime":"2016-06-29 03:33:15",
   "modifyTime":"2016-06-29 09:33:15",
   "size":"0.93M",
   "downloadUri":"http://msb_ip:msb_port/files/marketplace/CSAR/XYZ/NanocellGW/v1.0/NanocellGateway.csar",
   "type":"CSAR"
}

Query list of VNF package information by conditions

Interface Definition	Description
URI	/onapapi/marketplace/v1/csars?name={name}&version={version}&type={type}&provider={provider}
Operation Type	GET

Query Param

Attribute	Qualifier	Cardinality	Content	Description
name	M	1	String	csar Name
version	M	1	String	csar version
type	M	1	String	csar type
provider	M	1	String	csar provider

Response:

List of PackageMetaData

VNF Packaging Model/Blueprint

VNF product model/blueprint provides a declarative way to define deployment, operational and functional attributes of a VNF product. The VNF product is defined in terms of deployment time requirements and dependencies and exposed telemetry indicator definitions.

The deployment time requirements and dependencies define any and all compute infrastructure needs of the VNF product, such as specific hardware architecture, on-chip features, instruction set availability and hypervisor capabilities.

The telemetry indicator definitions define a set of default indicators exposed by a given VNF product for use by monitoring and assurance tools. This list can be extended and customized once a given VNF product is on-boarded and instantiated at run-time.

The VNF product model is specified using the TOSCA NFV simple profile. It is persisted, along with the product executables and data, using TOSCA CSAR files.

VNF SDK Marketplace

VNF SDK provides a reference implementation “marketplace” to help vendors validate and manage VNF packages. It also supports the operator to onboard VNF into ONAP.The API documentation using swagger can be found at http://hostIP:8702/apidocs or json yaml

VNF Repository is a reference repository for VNFs.
1. It provides functionalities such as:
  1. Upload/Re-upload VNF
  2. Download VNF
  3. Query VNF based on several parameters
  4. Delete VNF
2. It also provides an intuitive Graphical user interface to perform above activities.
Along with these, VNF SDK also provides hooks to call other tools or libraries including Validation and Function Tests.

a. Validation verifies the package structure, mandatory files and their format. Currently, the tool performs basic validation to support SDC. In a future release, it will also ensure integrity and authenticity of the package as described by VNF Requirements.

b. Function Test provides Robot framework test cases present in each VNF. Function test executes those test cases and send the test response back to the marketplace. While the framework is in place, actual test development is deferred for a future release.
VNF SDK Integration with SDC

a. In Amsterdam release, the SDC-UI is being integrated with the VNF Repository backend. It provides seamless download, search, view of the VNF present in VNF repository. The user can onboard these validated VNF into the SDC catalog.

VNF SDK Marketplace Installation Instructions

1. Download vnfsdk/refrepo from Gerrit

git clone http://gerrit.onap.org/r/vnfsdk/refrepo

2. Goto vnfmarket-be/deployment/install,

Delete old docker images of refrepo (if any).
Enter command "source .env" to set up few environment variables.
Enter command "docker-compose up -d"

This will start two Docker containers:

VNF Repository

PostgreSQL database.

Once started, access the Marketplace from your web browser.

Connect to http://{host}:8702/onapui/vnfmarket to access the user interface

VNF SDK Tools

VNF SDK tools provide VNF product DevOps engineers with command line tools and client side API language bindings to define the VNF product model and package content. The following tools are included…

VNF Package Builder - creates a CSAR file based on inputs provided by the VNF product DevOps engineer
VNF Package Validator - validates the content of the VNF packages to ensure that everything has been built correctly
VNF Package Extractor - extracts VNF product model and executables from the CSAR file
VNF Package Parser - translates VNF product blueprint into a format consumable by ONAP components
VNF Package Dry Run - performs a “dry run” install to ensure that the package can be deployed during instantiation

User Guides

VNF Package Tool

Provided tools

VNF Package Builder - creates a CSAR file based on inputs provided by the VNF product DevOps engineer
VNF Package Validator - validates the content of the VNF packages to ensure that everything has been built correctly
VNF Package Extractor - extracts VNF product model and executables from the CSAR file
VNF Package Parser - translates VNF product blueprint into a format consumable by ONAP components

The tools are provided in the form of a shared library (Python module) that can be used in other projects. A CLI is also provided out-of-the-box for DevOps to use the library with their scripts and automation framework.

Repository Name: vnfsdk/pkgtools

Clone command: git clone https://git.onap.org/vnfsdk/pkgtools

Installation

Python module with CLI is installed by Python pip command. It is possible to install into a virtual environment (virtualenv).

To install the vnfsdk package tool from source, run the following commands in the cloned repository directory:

$ pip install -r requirements.txt
$ pip install .

To install the vnfsdk pkgtools from onap hosted pypi repository, run the following commands in a python virtual environment:

$ pip install -i https://nexus3.onap.org/repository/PyPi.public/simple vnfsdk

Use VNF SDK package tools

Usage

Create CSAR by specifying a directory

vnfsdk [-v] csar-create [-h] -d DESTINATION [--manifest MANIFEST] [--history HISTORY]
[--tests TESTS] [--licenses LICENSES] [--digest {SHA256,SHA512}]
[--certificate CERTIFICATE] [--privkey PRIVKEY] source entry

e.g.

$ vnfsdk csar-create -d /tmp/helloworld.csar --manifest helloworld.mf --history ChangeLog.txt
--tests Tests --licenses Licenses --certificate test.crt --privkey test.key --digest SHA256
./hello-world/ helloworld.yaml

Extract CSAR content

vnfsdk -v csar-open [-h] -d DESTINATION [--no-verify-cert] source

e.g.

$ vnfsdk csar-open -d /tmp/helloworld --no-verify-cert /tmp/helloworld.csar

Validate CSAR content

vnfsdk -v csar-validate [-h] source

e.g.

$ vnfsdk csar-validate /tmp/helloworld.csar

All commands have -h switch which displays help and description of all parameters.

VNF Package Tools User Guide

VNF Package Designer, provides VNF product DevOps engineers with a graphical tool to define the VNF product model and package content. It is made available as part of the VNF Supplier SDK tools.The package designer makes use of the VNF SDK command line interfaces (CLIs) and client-side API language bindings in order to define the model and the package content. As such, it is functionally equivalent to the VNF SDK tools.

VNF SDK - Guide for Bundling VNFs

Step 1: Requirements

Virtual machine images for each of your VDUs (likely in qcow2 format).
Scripts for installing and configuring each VDU per the standard TOSCA lifecycle workflows.
Optional: scripts for retrieving indicators from each VDU.
VNF SDK pkgtools

Step 2: Start with the provided VNF blueprint as a template

The VNF SDK comes with a “pingpong.yaml” template.

Copy the file and rename it as is appropriate for your VNF.

Step 3: Edit the VNF blueprint

You will need a node template for each VDU, which in turn has a “dependency” requirement on a host (a Compute node template).

The “dependency” requirement should have a relationship of type “vnfsdk.DependsOn”.

There are two optional properties you can assign to this relationship:

“indicators” is a map of indicators. The keys are arbitrary, for you to name, and depend on the specific capabilities of your VNF. These provide the link between TOSCA and your indicator retrieval scripts.
“compute_dependencies” is a map of features you require the infrastructure to provide for the compute node hosting your VDU. The keys are arbitrary, however we will maintain a master list of names supported by various orchestrators (TBD). Note that new names will likely be supported in the future as technological innovation progresses, while deprecated ones will be ignored by orchestrators. Likewise, names unsupported by a particular orchestrator will be ignored.

Notes:

For “compute_dependencies”, you have the option of specifying a single special key, “profile”, that refers to a bundle of compute dependencies specified in “compute-profiles.yaml”. Optionally, you can override any of the dependencies in the bundle by specifying them explicitly under “compute_dependencies”.
By default, compute dependencies are considered to be absolute requirements for your VNF to function. However, if your VNF can also function without them, you can set “optional: true”. This way the orchestrator will try to satisfy the optional requirements, but will not report an error if it cannot.
You may optionally consider allowing operators to override your dependencies. This is useful for allowing the VNF to run on various compute infrastructures other than the defaults you specify, as long as they are indeed supported by your VNF. In TOSCA, this is easily handled by declaring “inputs” for your blueprint, with “default” values, and then using the “get_input” intrinsic function to apply the provided value to any specific “compute_dependencies”. The “pingpong.yaml” has an example of such usage. The same technique can be used to allow the operator to override your indicator scripts, and there is an example of that as well.

Otherwise, this is a standard TOSCA blueprint using the Simple Profile for NFV, and you may extend the blueprint as is required.

Step 4: Bundle the VNF

Arrange all your files (the TOSCA template, your scripts, and your virtual machine images) in the correct directory structure. File references provided in the blueprint must match the directory structure. If a script is referenced using a path with sub-directory “example” the initial directory must contain a directory called “example” with that script file inside. The directory structure will be kept inside the CSAR archive.

Run the bundling tool that is included in the VNF SDK.

The result will be a “.csar” file that can now be deployed by operators.

VNF SDK Marketplace User Guide for Operators

The VNF SDK Marketplace helps operators download pre-validated VNFs through the web GUI.

Log into the portal
Using the buttons in the upper right corner, an operator can see the currently validated VNFs in a list or grid view.
The marketplace provides an onboarding report for each VNF. Operators can see the testing results by clicking on the VNF. In the Amsterdam release, only validation tests are run. In the future, we plan to add lifecycle and functional tests.
Operators can download a VNF by clicking on the “download” button.
VNF SDK also supports integration with SDC. A VNF can be onboarded into SDC by visiting the SDC portal. SDC connects to VNF SDK and can query all available VNFs. When an operator selects a VNF in the SDC portal, it will be downloaded from VNFSDK and installed in the SDC catalog.

VNF SDK Marketplace User Guide for VNF Suppliers

The VNF SDK Marketplace helps vendors validate VNFs and connect with suppliers. To upload and validate VNFs, vendors will use the web GUI.

Log into the portal
Click “upload” in the upper right to upload a VNF. Select the file and enter a short description and details.
The file is uploaded into the system and the marketplace automatically starts the VNF validation process.
Once validation is complete, the VNF is installed in the marketplace.
A vendor can re-upload a VNF if there are changes by clicking the “re-upload” button.
A vendor can also delete a VNF by clicking the “delete” button.
Using the buttons in the upper right corner, a user can see a list or grid of VNFs.
The marketplace provides an onboarding report for each VNF. You can see the testing results by clicking on the VNF. In the Amsterdam release, only validation tests are run. In the future, we plan to add lifecycle and functional tests.

VNF SDK Marketplace User Guide for Rest API

The VNF SDK Marketplace expose rest API endpoints that allows validation of CSAR packages.

Parameters that need to be inserted are surrounded with {…}.

CSAR Validation - use all rules

Send and validate CSAR, against all active rules. If validation finish before timeout, result will be returned in json format. Otherwise executionId, that can be used for checking validation state in the future, will be returned.

curl --location --request POST 'http://{marketplace address}/onapapi/vnfsdk-marketplace/v1/vtp/executions' \
--header 'Content-Type: multipart/form-data' \
--form 'file=@"{path to csar file}"' \
--form 'executions="[{
  \"scenario\": \"onap-vtp\",
  \"testSuiteName\": \"validation\",
  \"testCaseName\": \"csar-validate\",
  \"parameters\": {
    \"csar\": \"file://{csar file name}\",
    \"pnf\":\"true\"
  }
}]"'

CSAR Validation - use selected rules

Send and validate CSAR, against selected rules. If validation finish before timeout, result will be returned in json format. Otherwise executionId, that can be used for checking validation state in the future, will be returned.

curl --location --request POST 'http://{marketplace address}/onapapi/vnfsdk-marketplace/v1/vtp/executions' \
--header 'Content-Type: multipart/form-data' \
--form 'file=@"{path to csar file}"' \
--form 'executions="[{
  \"scenario\": \"onap-vtp\",
  \"testSuiteName\": \"validation\",
  \"testCaseName\": \"csar-validate\",
  \"parameters\": {
    \"csar\": \"file://{csar file name}\",
    \"pnf\":\"true\",
    \"rules\":\"{rules to be validated example:r130206,r816745}\"
  }
}]"'

CSAR Validation - run validation for selected release

Send and validate a CSAR file using rules which have selected release. The ‘release’ parameter is optional and it can have one of the values: amsterdam, casablanca, dublin, frankfurt, guilin, honolulu, latest If user doesn’t set parameter then all rules will be used during validation. Otherwise rules are collected according to pattern: amsterdam rules <- casablanca rules <-dublin rules <-frankfurt rules <- guilin rules <- honolulu release <- latest For example: if user set release to dublin then rules with release dublin, casablanca and amsterdam will be used.

If validation finish before timeout, result will be returned in json format. Otherwise executionId, that can be used for checking validation state in the future, will be returned.

curl --location --request POST 'http://{marketplace address}/onapapi/vnfsdk-marketplace/v1/vtp/executions' \
--header 'Content-Type: multipart/form-data' \
--form 'file=@"{path to csar file}"' \
--form 'executions="[{
  \"scenario\": \"onap-vtp\",
  \"testSuiteName\": \"validation\",
  \"testCaseName\": \"csar-validate\",
  \"parameters\": {
    \"csar\": \"file://{csar file name}\",
    \"pnf\":\"true\",
    \"release\":\"dublin\"
  }
}]"'

CSAR Validation - get results of validation

Get result of CSAR validation connected with executionId. Returns result in json format.

curl --location --request GET 'http://{marketplace address}/onapapi/vnfsdk-marketplace/v1/vtp/executions?requestId={executionId}'

Example

Request:

curl --location --request POST 'http://127.0.0.1:8702/onapapi/vnfsdk-marketplace/v1/vtp/executions' \
--header 'Content-Type: multipart/form-data' \
--form 'file=@"/csar/invalidSignaturePackage.csar"' \
--form 'executions="[{
  \"scenario\": \"onap-vtp\",
  \"testSuiteName\": \"validation\",
  \"testCaseName\": \"csar-validate\",
  \"parameters\": {
    \"csar\": \"file://invalidSignaturePackage.csar\",
    \"pnf\":\"true\",
    \"rules\":\"r130206,r816745\"
  }
}]"'

Response:

[
    {
        "scenario": "onap-vtp",
        "testCaseName": "csar-validate",
        "testSuiteName": "validation",
        "executionId": "5e7a1726-4c48-42b9-ade4-dfd12ea75107-1608035294086",
        "parameters": {
            "csar": "/tmp/data/vtp-tmp-files/invalidSignaturePackage.csar",
            "pnf": "true",
            "rules": "r130206,r816745"
        },
        "results": {
            "vnf": {
                "name": "RadioNode",
                "vendor": "Ericsson",
                "version": "1.0",
                "type": "TOSCA",
                "mode": "WITH_TOSCA_META_DIR"
            },
            "date": "Tue Dec 15 12:28:14 UTC 2020",
            "criteria": "FAILED",
            "results": [
                {
                    "passed": true,
                    "vnfreqName": "SOL004",
                    "description": "V2.4.1 (2018-02)",
                    "errors": [],
                    "warnings": []
                },
                {
                    "passed": false,
                    "vnfreqName": "r130206",
                    "description": "The VNF/PNF package shall contain a Digest (a.k.a. hash) for each of the components of the VNF package. The table of hashes is included in the manifest file, which is signed with the VNF provider private key. In addition, the VNF provider shall include a signing certificate that includes the VNF provider public key, following a pre-defined naming convention and located either at the root of the archive or in a predefined location (e.g. directory).",
                    "errors": [
                        {
                            "vnfreqNo": "R130206",
                            "code": "0x4007",
                            "message": "File has invalid signature!",
                            "lineNumber": -1
                        }
                    ],
                    "warnings": []
                },
                {
                    "passed": false,
                    "vnfreqName": "r816745",
                    "description": "The VNF or PNF PROVIDER MUST provide the Service Provider with Meta Data (Dictionary)\nto support the analysis of events delivered to DCAE.\nThe Dictionary is to be provided as a separate YAML artifact at onboarding and must follow\nthe VES Event Listener Specification and VES Event Registration Specification\nwhich contain the format and content required.",
                    "errors": [
                        {
                            "vnfreqNo": "R816745",
                            "code": "0x2000",
                            "message": "Fail to load Dictionary With error: Dictionary YAML file is empty",
                            "file": "Artifacts/Deployment/Measurements/Dictionary.yml",
                            "lineNumber": -1
                        }
                    ],
                    "warnings": []
                }
            ],
            "contact": "ONAP VTP Team onap-discuss@lists.onap.org",
            "platform": "VNFSDK - VNF Test Platform (VTP) 1.0"
        },
        "status": "COMPLETED",
        "startTime": "2020-12-15T12:28:11.895",
        "endTime": "2020-12-15T12:28:14.962"
    }
]

Dovetail Integration

User Stories

An ONAP User wants to ensure that VNFs which appear in the VNF Marketplace can be on-boarded with the Service Design & Creation tool without errors.
An ONAP User would like to be able to run VNF Certification tests on demand using a common user interface independent of the test being run.
An ONAP Certification Authority wants a central repository in which to examine the results of tests run by ONAP Users
An ONAP Certification Authority wants to be able to determine that VNF certification tests run by ONAP Users were executed properly.
An ONAP VNF Test Developer wants a consistent environment in which to develop tests.

OPNFV Dovetail Description

The Open Platform for NFV (OPNFV) is a collaborative project under the Linux Foundation that is transforming global networks through open source Network Functions Virtualization (NFV). OPNFV focuses on developing test suites for Open Source implementations of the NFV infrastructure components such as those specified in the ETSI NFV ISG MANO architecture. Areas of focus in OPNFV include: Virtualized Infrastructure Managers (VIM) such as OpenStack and Software Defined Networking Controllers (SDNC) such as Open Daylight.

The OPNFV Dovetail project is responsible for the testing framework in OPNFV. The Dovetail testing framework is currently used by all of the active OPNFV projects. Dovetail has been through ~3 OPNFV release cycles and has been hardened in the process. The Dovetail community includes ~15 companies and ~20 active developers.

The Dovetail test framework includes the following features which make it ideal as the test framework for VNF certification testing:

Provides a Generic Test Framework

While the Dovetail project is currently being used in OPNFV as the test framework for NFV infrastructure testing, there is nothing that limits the Dovetail test framework to NFV infrastructure testing. This allows the same test framework to be used across multiple NFV initiatives (OPNFV and ONAP) and across multiple (NFV infrastructure and VNF certification) test suites.

Separates the Vendor and Certification Authority environment

Dovetail uses an authenticated REST interface which is used by the test environment to report test results to the test repository. This allows the test repository to be located in a different administrative domain than the test runtime environment.

Separates the test environment from the test framework environment

Dovetail launches tests in a Docker container. This provides some isolation of the test environment from the test framework environment.

Figure 1 below illustrates the Dovetail test framework architecture.

Figure 1: OPNFV Dovetail Test Framework Architecture

Implementation Overview

OPNFV Dovetail will be integrated into the ONAP VNF Marketplace. The ONAP VNF Marketplace is an ONAP application which displays all VNFs that are available in an ONAP instantiation for incorporation into an ONAP Network Service. Dovetail will be integrated into the VNF Marketplace ingest flow and will also be available as a general service which can be used to run additional VNF certification tests after the VNF Package has been uploaded to the VNF Marketplace.

The VNF Marketplace ingest flow performs basic tests on a VNF package before it is uploaded into the ONAP VNF Marketplace. Tests which fall into this category will be incorporated into the ONAP VNF Package Validation test suite.

The Dovetail client will also be available as a service in the VNF Marketplace. The Dovetail client is an interactive application which allows additional VNF Certification tests to be run on a VNF after the VNF Package has been uploaded to the VNF Marketplace. The Dovetail client will indicate which certification tests have been successfully run on each VNF in the VNF Marketplace. VNF Vendors that are interested in obtaining additional certifications for VNFs that have been uploaded in the marketplace will have the ability to work with Certification Test suppliers to obtain and run advanced certification tests. Figure 2 illustrates how the VNF Certification Framework is being integrated into ONAP.

Figure 2: ONAP VNF Certification Framework

Figure 2 illustrates the flow that is used to execute the VNF Package On Boarding test suite as part of the VNF ingest flow of the ONAP VNF Marketplace.

Initiate Upload

The VNF Vendor initiates a VNF upload request to the ONAP VNF Marketplace. This API call includes a reference to the VNF Package the vendor wants to upload.

Download testing client

The VNF Marketplace executes the VNF Package On Boarding test suite as part of the VNF ingest flow. The first step in this process is to instantiate the Dovetail testing client. The Dovetail client is instantiated with a parameter which specifies the name of the test suite that Dovetail will execute. In this case Dovetail will execute the VNF Package On Boarding test suite.

Start Testing Flow

Dovetail creates a Docker container for the test environment for each test in the test suite. The VNF Package On Boarding test suite includes tests which examine the contents of the contents of the VNF package, examine the orchestration template, and examine the VM image(s) of the VNF. Tests which use ONAP services will send asynchronous requests to the service via the ONAP Micro Services bus.

Check Progress

Tests may check the status of ONAP services which are instantiated asynchronously.

Examine VNF

ONAP services used by the VNF Package On Boarding test suite may need to access components of the VNF package for validate their content.

Report Certification Results Back

As each test progresses, results are reported back through the Dovetail framework to the certification database. In this case, the certification database is local to the ONAP VNF Marketplace.

If all of the tests in the VNF Package On Boarding test suite complete successfully, then the VNF Package and its contents are stored in the VNF Marketplace where they can be used for further ONAP VNF On Boarding processes.

Implementation Details

Introduce a new test module under VNFSDK

A new test module ‘VnfTest’ will be added as a subproject in VNF-SDK.

This project will be similar to ‘Yardstick’ in the way it defines and runs tests.

Dovetail to support new type

A new test framework type will be introduced to dovetail – “VNFTest”.

Dovetail will handle the new type in the same way yardstick/functest types are handled.

When dovetail needs to fetch the “VnfTest” docker image, it will consult with configuration for determining the exact image name and version.

The “VnfTest” framework is expected to support the same APIs and format currently used between dovetail and yardstick/functest.

VNF SDK Compliance Verification Program

Background

LF Networking is providing a testing program to demonstrate SDN/NFV capabilities and interoperability.

Program began with OPNFV Verified Programs

Supports both self-testing and third-party lab testing
Initial version will test VIM+NFVI

We propose expanding the program in 2018 to include VNF Compliance

Requirements and tests defined by ONAP
Test framework provided by OPNFV(Dovetail) and ONAP VNF Test Platform (VTP)
Back-end infrastructure provided by Linux Foundation

CVC Structures

VNF Test Platform (VTP)

Deploy VNF/PNF test cases once and trigger it safely from anywhere

Objectives

LFN/ONAP wants test platform where VNF packages could be certified using ONAP requirements to drive industry adoption
Provide an platform where vendor/operator can develop, deploy, run test cases and query the results
Test cases, test results and VNF should be manageable .i,e with authorization, so only user with given roles is allowed to perform operation like VNF package upload/download, run compliance verification tests, allow only specific VIM for specific users, etc.
Test results should be persisted and should be available for human analysis later via LFN infrastructure.
Provides test flow where author make flow across different test cases for a given program like compliance verification and VNFREQS/SOL0004.
Provide integration with OPNFV dovetail to run test cases across dovetail and VNFSDK.
Deployable as docker container.

Architecture

VTP deployment

Install VTP Backend

export NEXUS_DOCKER_REPO=nexus3.onap.org:10001

docker login $NEXUS_DOCKER_REPO -u docker -p docker

export REFREPO_TAG=1.3.0

export POSTGRES_TAG=latest

export MTU=1450

wget https://raw.githubusercontent.com/onap/vnfsdk-refrepo/master/vnfmarket-be/deployment/install/docker-compose.yml

docker-compose up -d

run docker ps and following entries would be reported:

root@mrkanag:~# docker ps
CONTAINER ID        IMAGE                                                       COMMAND                  CREATED             STATUS              PORTS                                                                                NAMES
4d42ef0bc1b3        nexus3.onap.org:10001/onap/vnfsdk/refrepo:1.3.0             "/service/docker-ent…"   2 days ago          Up 2 days           0.0.0.0:8000->8000/tcp, 0.0.0.0:8702-8703->8702-8703/tcp, 0.0.0.0:50051->50051/tcp   refrepo
25a86d9b0e81        nexus3.onap.org:10001/onap/vnfsdk/refrepo/postgres:latest   "docker-entrypoint.s…"   2 days ago          Up 2 days           0.0.0.0:5432->5432/tcp                                                               postgres

VTP usage guide

1. List scenario:

GET {{vtp-host}}/onapapi/vnfsdk-marketplace/v1/vtp/scenarios

[
   {
       "name": "scenario-1",
       "description": "Test scenario 1 \n"
   },
   {
       "name": "scenario-2",
       "description": "Test scenario 1 \n"
   },
   {
       "name": "open-cli",
       "description": "OPEN CLI PLATFORM provides a dynamic platform to load and execute commands\nbased on the Open Command Specification (OCS) 1.0. \n"
   }
]

2. List Test suites:

GET {{vtp-host}}/onapapi/vnfsdk-marketplace/v1/vtp/scenarios/scenario-1/testsuites
[
   {
       "name": "testsuite-1",
       "description": "testsuite 1"
   },
   {
       "name": "testsuite-2",
       "description": "testsuite 2"
   }
]

3. List Test cases:

GET {{vtp-host}}/onapapi/vnfsdk-marketplace/v1/vtp/scenarios/scenario-1/testcases
[
   {
       "testCaseName": "s1.ts1.testcase-1",
       "testSuiteName": "testsuite-1"
   },
   {
       "testCaseName": "s1.ts1.testcase-2",
       "testSuiteName": "testsuite-1"
   },
   {
       "testCaseName": "s1.ts1.testcase-3",
       "testSuiteName": "testsuite-1"
   },
   {
       "testCaseName": "s1.ts2.testcase-1",
       "testSuiteName": "testsuite-2"
   },
   {
       "testCaseName": "s1.ts2.testcase-2",
       "testSuiteName": "testsuite-2"
   }
]

4. Show Test case details:

GET {{vtp-host}}/onapapi/vnfsdk-marketplace/v1/vtp/scenarios/scenario-1/testsuites/testsuite-1/testcases/s1.ts1.testcase-1

{
   "testCaseName": "s1.ts1.testcase-1",
   "testSuiteName": "testsuite-1",
   "descripton": "s1.ts1.testcase-1",
   "author": "Kanagaraj Manickam kanagaraj.manickam@huawei.com",
   "inputs": [
       {
           "name": "input1",
           "description": "Input 1",
           "type": "string",
           "isOptional": false,
           "metadata": {
               "allowed_value": [
                   "a",
                   "b",
                   "c"
               ]
           }
       },
       {
           "name": "input2",
           "description": "Input 2",
           "type": "string",
           "defaultValue": "v2",
           "isOptional": true
       }
   ],
   "outputs": [
       {
           "name": "output1",
           "description": "output 1",
           "type": "string"
       }
   ]
}

5. List Test cases in test suite:

GET {{vtp-host}}/onapapi/vnfsdk-marketplace/v1/vtp/scenarios/scenario-2/testcases?testSuiteName=testsuite-1
[
   {
       "testCaseName": "s2.ts1.testcase-1",
       "testSuiteName": "testsuite-1"
   }
]

6. Run a test case:

 GET {{vtp-host}}/onapapi/vnfsdk-marketplace/v1/vtp/executions
[
   {
       "scenario": "open-cli",
       "testCaseName": "schema-list",
       "testSuiteName": "schema",
       "executionId": "00dfda6c-df16-4c5b-a731-3d531a7aafa5-1550505316115",
       "requestId": "00dfda6c-df16-4c5b-a731-3d531a7aafa5",
       "status": "completed",
       "startTime": "2019-02-18T15:55:16.138",
       "endTime": "2019-02-18T15:55:16.220"
   }
]

7. Retrieve the execution result:

GET {{vtp-host}}/onapapi/vnfsdk-marketplace/v1/vtp/executions/ebaa5f21-ed68-4098-97a9-775ac8800f09-1550575025614
{
   "scenario": "scenario-1",
   "testCaseName": "s1.ts2.testcase-1",
   "testSuiteName": "testsuite-2",
   "executionId": "ebaa5f21-ed68-4098-97a9-775ac8800f09-1550575025614",
   "parameters": {
       "input2": "v2",
       "input1": "v1"
   },
   "results": {
       "output1": "v1=v2"
   },
   "status": "completed",
   "startTime": "2019-02-19T11:17:05.670",
   "endTime": "2019-02-19T11:17:05.683"
}

8. Execute test case without file content (across scenario, test suites):

POST {{vtp-host}}/onapapi/vnfsdk-marketplace/v1/vtp/executions?requestId=ebaa5f21-ed68-4098-97a9-775ac8800f09
content-type multipart/form-data
BODY:
 executions:
 [{
 "scenario": "scenario-1",
 "testSuiteName": "testsuite-1",
 "testCaseName": "s1.ts1.testcase-1",
 "parameters": {
   "input1": "v1",
   "input2": "v2"
 }
 },{
 "scenario": "scenario-1",
 "testSuiteName": "testsuite-2",
 "testCaseName": "s1.ts2.testcase-1",
 "parameters": {
   "input1": "v1"
 }
 },
 {
 "scenario": "open-cli",
 "testSuiteName": "schema",
 "testCaseName": "schema-validate",
 "parameters": {
     "schema-location": "file://s1.ts1.testcase-1.yaml"
 }
}]

RESPONSE:
[
   {
       "scenario": "scenario-1",
       "testCaseName": "s1.ts1.testcase-1",
       "testSuiteName": "testsuite-1",
       "executionId": "ebaa5f21-ed68-4098-97a9-775ac8800f09-1550575025516",
       "parameters": {
           "input1": "v1",
           "input2": "v2"
       },
       "results": {
           "output1": "v1-v2"
       },
       "status": "COMPLETED",
       "startTime": "2019-02-19T11:17:05.464",
       "endTime": "2019-02-19T11:17:05.579"
   },
   {
       "scenario": "scenario-1",
       "testCaseName": "s1.ts2.testcase-1",
       "testSuiteName": "testsuite-2",
       "executionId": "ebaa5f21-ed68-4098-97a9-775ac8800f09-1550575025614",
       "parameters": {
           "input1": "v1"
       },
       "results": {
           "output1": "v1=v2"
       },
       "status": "COMPLETED",
       "startTime": "2019-02-19T11:17:05.579",
       "endTime": "2019-02-19T11:17:05.701"
   }
]

9. Execute test case with file content:

POST {{vtp-host}}/onapapi/vnfsdk-marketplace/v1/vtp/executions?requestId=ebaa5f21-ed68-4098-97a9-775ac8800f07
content-type multipart/form-data
BODY:
 file -- file  s1.ts1.testcase-1.yaml content
 executions:
 [{
 "scenario": "open-cli",
 "testSuiteName": "schema",
 "testCaseName": "schema-validate",
 "parameters": {
     "schema-location": "file://s1.ts1.testcase-1.yaml"
 }
 }]

RESPONSE:
[
   {
       "scenario": "open-cli",
       "testCaseName": "schema-validate",
       "testSuiteName": "schema",
       "executionId": "ebaa5f21-ed68-4098-97a9-775ac8800f07-1550575843353",
       "parameters": {
           "schema-location": "d:/temp/vtp/temp-files/s1.ts1.testcase-1.yaml"
       },
       "results": [
           {}
       ],
       "status": "COMPLETED",
       "startTime": "2019-02-19T11:30:43.288",
       "endTime": "2019-02-19T11:30:43.672"
   }
]

Reference

ONAP VTP Wiki.

CSAR Compliance check for SOL004 and SOL001

ONAP enabled the required compliance check by following VNFREQS and reports the non-compliant entries as errors.

When VNF Test Platform (VTP) is deployed, by default this testing is enabled with test case name as below

scenario: onap-vtp

testsuite: validation

testcase: csar-validate

And every VNFREQS is modeled as separate test case with name csar-validate-rxxxxx, where xxxxx represents the VNFREQS.

Active VNF requirements

Table of VNF active requirements.
Product	Release	Requirement No.	Description
onap-vtp	casablanca	r02454	The VNF MUST support the existence of multiple major/minor versions of the VNF software and/or sub-components and interfaces that support both forward and backward compatibility to be transparent to the Service Provider usage.
onap-vtp	casablanca	r04298	VNF provider MUST provider their testing scripts to support testing
onap-vtp	casablanca	r35851	The VNF Package MUST include VNF topology that describes basic network and application connectivity internal and external to the VNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if applicable) for each interface.
onap-vtp	casablanca	r66070	The VNF Package MUST include VNF Identification Data to uniquely identify the resource for a given VNF provider. The identification data must include: an identifier for the VNF, the name of the VNF as was given by the VNF provider, VNF description, VNF provider, and version
onap-vtp	casablanca	r77707	VNF provider MUST include manifest file that contains a list of all the components in VNF package
onap-vtp	casablanca	r77786	The VNF Package MUST include all relevant cookbooks to be loaded on the ONAP Chef Server.
onap-vtp	dublin	r01123	The VNF or PNF CSAR package Manifest file MUST contain: VNF or PNF package meta-data, a list of all artifacts (both internal and external) entry’s including their respected URI’s, an algorithm to calculate a digest and a digest result calculated on the content of each artifacts, as specified in ETSI GS NFV-SOL004. The VNF or PNF Package MUST include VNF or PNF Identification Data to uniquely identify the resource for a given provider. The identification data must include: an identifier for the VNF or PNF, the name of the VNF or PNF as was given by the provider, description, provider and version.
onap-vtp	dublin	r07879	The VNF Package MUST include all relevant playbooks to ONAP to be loaded on the Ansible Server.
onap-vtp	dublin	r09467	The VNF MUST utilize only NCSP standard compute flavors. [5] - compute, virtual storage.
onap-vtp	dublin	r10087	The VNF package MUST contain all standard artifacts as specified in ETSI GS NFV-SOL004 including Manifest file, VNFD (or Main TOSCA/YAML based Service Template) and other optional artifacts. CSAR Manifest file as per SOL004 - for example ROOTMainServiceTemplate.mf
onap-vtp	dublin	r13390	The VNF provider MUST provide cookbooks to be loaded on the appropriate Chef Server.
onap-vtp	dublin	r15837	Major TOSCA Types specified in ETSI NFV-SOL001 standard draft.
onap-vtp	dublin	r17852	The VNFD/PNFD MAY include TOSCA/YAML definitions that are not part of NFV Profile. If provided, these definitions MUST comply with TOSCA Simple Profile in YAML v.1.2.
onap-vtp	dublin	r21322	The VNF provider MUST provide their testing scripts to support testing as specified in ETSI NFV-SOL004 - Testing directory in CSAR.
onap-vtp	dublin	r23823	The VNF Package MUST include appropriate credentials so that ONAP can interact with the Chef Server
onap-vtp	dublin	r26881	The VNF provider MUST provide the binaries and images needed to instantiate the VNF (VNF and VNFC images).
onap-vtp	dublin	r26885	The VNF provider MUST provide the binaries and images needed to instantiate the VNF (VNF and VNFC images) either as: Local artifact in CSAR: ROOTArtifactsVNF_Image.bin externally referred (by URI) artifact in Manifest file (also may be referred by VNF Descriptor) Note: Currently, ONAP doesn’t have the capability of Image management, we upload the image into VIM/VNFM manually.
onap-vtp	dublin	r27310	The VNF Package MUST include all relevant Chef artifacts (roles/cookbooks/recipes) required to execute VNF actions requested by ONAP for loading on appropriate Chef Server.
onap-vtp	dublin	r32155	The VNFD provided by VNF vendor may use the below described TOSCA interface types. An on-boarding entity (ONAP SDC) MUST support them..
onap-vtp	dublin	r35854	The VNF/PNF Descriptor (VNFD/PNFD) provided by VNF/PNF vendor MUST comply with TOSCA/YAML based Service template for VNF/PNF descriptor specified in ETSI NFV-SOL001.
onap-vtp	dublin	r40293	The VNF MUST make available (or load on VNF Ansible Server) playbooks that conform to the ONAP requirement.
onap-vtp	dublin	r40820	The VNF provider MUST enumerate all of the open source licenses their VNF(s) incorporate. CSAR License directory as per ETSI SOL004. for example ROOTLicensesLicense_term.txt
onap-vtp	dublin	r43958	The VNF Package MUST include documentation describing the tests that were conducted by the VNF provider and the test results.
onap-vtp	dublin	r46527	A VNFD is a deployment template which describes a VNF in terms of deployment and operational behavior requirements. It contains virtualized resources (nodes) requirements as well as connectivity and interfaces requirements and MUST comply with info elements specified in ETSI GS NFV-IFA 011.
onap-vtp	dublin	r51347	The VNF package MUST be arranged as a CSAR archive as specified in TOSCA Simple Profile in YAML 1.2.
onap-vtp	dublin	r54356	Data types used by NFV node and is based on TOSCA/YAML constructs specified in draft GS NFV-SOL 001. The node data definitions/attributes used in VNFD MUST comply.
onap-vtp	dublin	r65486	The VNFD MUST comply with ETSI GS NFV-SOL001 document endorsing the above mentioned NFV Profile and maintaining the gaps with the requirements specified in ETSI GS NFV-IFA011 standard.
onap-vtp	dublin	r67895	The VNFD provided by VNF vendor may use the below described TOSCA capabilities. An on-boarding entity (ONAP SDC) MUST support them.
onap-vtp	dublin	r87234	The VNF/PNF package provided by a VNF/PNF vendor MAY be either with TOSCA-Metadata directory (CSAR Option 1) or without TOSCA-Metadata directory (CSAR Option 2) as specified in ETSI GS NFV-SOL004. On-boarding entity (ONAP SDC) must support both options.
onap-vtp	dublin	r95321	The VNFD provided by VNF vendor may use the below described TOSCA relationships. An on-boarding entity (ONAP SDC) MUST support them.
onap-vtp	dublin	r787965	If the VNF or PNF CSAR Package utilizes Option 2 for package security, then the complete CSAR file MUST be digitally signed with the VNF or PNF provider private key. The VNF or PNF provider delivers one zip file consisting of the CSAR file, a signature file and a certificate file that includes the VNF or PNF provider public key. The certificate may also be included in the signature container, if the signature format allows that. The VNF or PNF provider creates a zip file consisting of the CSAR file with .csar extension, signature and certificate files. The signature and certificate files must be siblings of the CSAR file with extensions .cms and .cert respectively.
onap-vtp	guilin	r130206	The VNF/PNF package shall contain a Digest (a.k.a. hash) for each of the components of the VNF package. The table of hashes is included in the manifest file, which is signed with the VNF provider private key. In addition, the VNF provider shall include a signing certificate that includes the VNF provider public key, following a pre-defined naming convention and located either at the root of the archive or in a predefined location (e.g. directory).

Active PNF requirements

Table of PNF active requirements.
Product	Release	Requirement No.	Description
onap-vtp	dublin	r01123	The VNF or PNF CSAR package Manifest file MUST contain: VNF or PNF package meta-data, a list of all artifacts (both internal and external) entry’s including their respected URI’s, an algorithm to calculate a digest and a digest result calculated on the content of each artifacts, as specified in ETSI GS NFV-SOL004. The VNF or PNF Package MUST include VNF or PNF Identification Data to uniquely identify the resource for a given provider. The identification data must include: an identifier for the VNF or PNF, the name of the VNF or PNF as was given by the provider, description, provider and version.
onap-vtp	dublin	r10087	The VNF package MUST contain all standard artifacts as specified in ETSI GS NFV-SOL004 including Manifest file, VNFD (or Main TOSCA/YAML based Service Template) and other optional artifacts. CSAR Manifest file as per SOL004 - for example ROOTMainServiceTemplate.mf
onap-vtp	dublin	r15837	Major TOSCA Types specified in ETSI NFV-SOL001 standard draft.
onap-vtp	dublin	r17852	The VNFD/PNFD MAY include TOSCA/YAML definitions that are not part of NFV Profile. If provided, these definitions MUST comply with TOSCA Simple Profile in YAML v.1.2.
onap-vtp	dublin	r35854	The VNF/PNF Descriptor (VNFD/PNFD) provided by VNF/PNF vendor MUST comply with TOSCA/YAML based Service template for VNF/PNF descriptor specified in ETSI NFV-SOL001.
onap-vtp	dublin	r57019	The PNF TOSCA CSAR package Manifest file MUST start with the PNF package metadata in the form of a name-value pairs. Each pair shall appear on a different line. The name is specified as following: -pnfd_provider -pnfd_name -pnfd_release_date_time -pnfd_archive_version
onap-vtp	dublin	r87234	The VNF/PNF package provided by a VNF/PNF vendor MAY be either with TOSCA-Metadata directory (CSAR Option 1) or without TOSCA-Metadata directory (CSAR Option 2) as specified in ETSI GS NFV-SOL004. On-boarding entity (ONAP SDC) must support both options.
onap-vtp	dublin	r146092	The VNF/PNF package Manifest file MUST contain: non-mano artifact set with following ONAP public tag -onap_ansible_playbooks -onap_others -onap_pm_dictionary -onap_pnf_sw_information -onap_scripts -onap_ves_events -onap_yang_modules
onap-vtp	dublin	r293901	For a VNF/PNF package CSAR MUST contains a TOSCA-Metadata directory with the TOSCA.meta metadata file. The TOSCA.meta metadata file MUST includes block_0 with the Entry-Definitions keyword pointing to a TOSCA definitions YAML file. Additional keyname extension must be included as following: -ETSI-Entry-Manifest -ETSI-Entry-Change-Log
onap-vtp	dublin	r787965	If the VNF or PNF CSAR Package utilizes Option 2 for package security, then the complete CSAR file MUST be digitally signed with the VNF or PNF provider private key. The VNF or PNF provider delivers one zip file consisting of the CSAR file, a signature file and a certificate file that includes the VNF or PNF provider public key. The certificate may also be included in the signature container, if the signature format allows that. The VNF or PNF provider creates a zip file consisting of the CSAR file with .csar extension, signature and certificate files. The signature and certificate files must be siblings of the CSAR file with extensions .cms and .cert respectively.
onap-vtp	frankfurt	r972082	The PNF software information file is included in the package and it MUST be compliant to: - The file extension which contains the PNF software version must be .yaml - The PNF software version information must be specified as following: onap_pnf_sw_information: - pnf_software_version: “<version>”
onap-vtp	guilin	r130206	The VNF/PNF package shall contain a Digest (a.k.a. hash) for each of the components of the VNF package. The table of hashes is included in the manifest file, which is signed with the VNF provider private key. In addition, the VNF provider shall include a signing certificate that includes the VNF provider public key, following a pre-defined naming convention and located either at the root of the archive or in a predefined location (e.g. directory).
onap-vtp	guilin	r816745	The VNF or PNF PROVIDER MUST provide the Service Provider with PM Meta Data (PM Dictionary) to support the analysis of PM events delivered to DCAE. The PM Dictionary is to be provided as a separate YAML artifact at onboarding and must follow the VES Event Listener Specification and VES Event Registration Specification which contain the format and content required.

OCLIP additional parameters in Dublin

To run validation of PNF csar additional –pnf parameter must be used.

oclip –product onap-vtp csar-validate –pnf –csar <path to pnf.csar or package.zip>

Package zip structure

Generate certificates

openssl req -nodes -x509 -sha256 -newkey rsa:4096 -keyout “pnf.key” -out “pnf.cert” -days 365 -subj “/C=NL/ST=Zuid Holland/L=Rotterdam/O=Sparkling Network/OU=IT Dept/CN=$(whoami)s Sign Key”

Sign csar file with the private key

openssl dgst -sha256 -sign “pnf.key” -out pnf.sha256.cms pnf.csar

Verify signature

openssl dgst -sha256 -verify <(openssl x509 -in “pnf.cert” -pubkey -noout) -signature pnf.sha256.cms pnf.csar

VNFSDK Dictionary Validation User Guide

Library was created to validate Dictionary YAML files which are used in a xNF ETSI NFV onboarding packages - CSAR files.

Basic information

The Dictionary validation library has two versions:

validation-dictionary-<version>.jar contains Dictionary YAML validation logic which can be used by any ONAP component. Currently it is used by VNFSDK and SDC.
validation-dictionary-<version>-standalone.jar contains Dictionary YAML validation logic which can be run from command line.

The Dictionary validation can be started in the two ways:

as a standalone application
using an Oclip command

Release Note

The standalone version of Dictionary validation library is available from Honolulu release.

How to download standalone version

All available jars are available at

https://nexus.onap.org/#nexus-search;quick~validation-dictionary

To download a standalone version of Dictionary validation library you need to prepare a link for selected version of file or manually download the file from Nexus (Viewing Repository: Releases).

Template

wget -O validation-dictionary-<VERSION>-standalone.jar https://nexus.onap.org/service/local/artifact/maven/redirect?r=releases&g=org.onap.vnfsdk.validation&a=validation-dictionary&v=<VERSION>&e=jar&c=standalone

For example link for version 1.2.16 looks like

wget -O validation-dictionary-1.2.16-standalone.jar https://nexus.onap.org/service/local/artifact/maven/redirect?r=releases&g=org.onap.vnfsdk.validation&a=validation-dictionary&v=1.2.16&e=jar&c=standalone

Application return codes

Return code	Description
0	No errors, validation passed
1	Validation fails
2	Internal application error

Application outputs

Output	Description
Console	All information’s about operation progress, result and errors are logged at user console.
Log file	Application creates a log file where all information’s generated by application are logged.
Result json file	Validation result is also available in the file with postfix ‘-validation-results.json’. The File is stored in a folder with input dictionary file.

How to run standalone application?

Install Java 11 JRE
Download standalone version of Dictionary YAML validation application

For example

wget -O validation-dictionary-1.2.16-standalone.jar https://nexus.onap.org/service/local/artifact/maven/redirect?r=snapshots&g=org.onap.vnfsdk.validation&a=validation-dictionary&v=1.2.16&e=jar&c=standalone

3. Go to folder with downloaded application and run it

java -jar validation-dictionary-1.2.16-standalone.jar <path to dictionary_file.yaml>

Examples

1. Successful validation

❯ java -jar validation-dictionary-1.2.16-standalone.jar /home/username/yaml_schema/Simple_Valid_Schema.yaml

# Executing a 'Validate Dictionary yaml' operation ...
# ... Done.

# Operation result:

{
    "file": "/home/username/yaml_schema/Simple_Valid_Schema.yaml",
    "status": "PASS",
    "errors": []
}

# Result was stored in a file: '/home/username/yaml_schema/Simple_Valid_Schema-validation-results.json'

# Application exits successfully.

❯ echo $?
0

❯ cat Simple_Valid_Schema-validation-results.json

{
    "file": "/home/username/yaml_schema/Simple_Valid_Schema.yaml",
    "status": "PASS",
    "errors": []
}

2. Failing validation

❯ java -jar validation-dictionary-1.2.16-standalone.jar /home/username/yaml_schema/Dictionary.yaml

# Executing a 'Validate Dictionary yaml' operation ...
# ... Done.

# Operation result:

{
    "file": "/home/username/yaml_schema/Dictionary.yaml",
    "status": "FAILED",
    "errors": [
            {
              "yamlDocumentNumber": 1,
              "path": "/MetaData/Fields/measResultType",
              "message": "Value(s) is/are not in array of accepted values.\n value(s):  integer\n  accepted value(s):  [float, uint32, uint64]"
            },
            {
              "yamlDocumentNumber": 1,
              "path": "/MetaData/Fields/",
              "message": "Key not found: measChangeType"
            },
            {
              "yamlDocumentNumber": 2,
              "path": "/MetaData/Fields/",
              "message": "Key not found: measChangeType"
            },
            {
              "yamlDocumentNumber": 3,
              "path": "/MetaData/Fields/measAdditionalFields/vendorField1",
              "message": "Value(s) is/are not in array of accepted values.\n value(s):  [Z, A]\n  accepted value(s):  [X, Y, Z]"
            }
    ]
}

# Result was stored in a file: '/home/username/yaml_schema/Dictionary-validation-results.json'

# Application exits successfully.

❯ echo $?
1

❯ cat /home/username/yaml_schema/Dictionary-validation-results.json

{
    "file": "/home/username/yaml_schema/Dictionary.yaml",
    "status": "FAILED",
    "errors": [
            {
              "yamlDocumentNumber": 1,
              "path": "/MetaData/Fields/measResultType",
              "message": "Value(s) is/are not in array of accepted values.\n value(s):  integer\n  accepted value(s):  [float, uint32, uint64]"
            },
            {
              "yamlDocumentNumber": 1,
              "path": "/MetaData/Fields/",
              "message": "Key not found: measChangeType"
            },
            {
              "yamlDocumentNumber": 2,
              "path": "/MetaData/Fields/",
              "message": "Key not found: measChangeType"
            },
            {
              "yamlDocumentNumber": 3,
              "path": "/MetaData/Fields/measAdditionalFields/vendorField1",
              "message": "Value(s) is/are not in array of accepted values.\n value(s):  [Z, A]\n  accepted value(s):  [X, Y, Z]"
            }
    ]
}

3. Validation internal error

❯ java -jar validation-dictionary-1.2.16-standalone.jar /home/username/Not_Yaml_File.txt

# Executing a 'Validate Dictionary yaml' operation ...
# Command error:
Provided yaml file has invalid structure!, more information in log file.

# Application fails with internal error.

❯ echo $?
2

❯ cat dictionary-validate.log

2020-12-14 08:23:31,054 ERROR o.o.v.y.YamlLoader [main] Failed to load multi document YAML file
...

How to run Dictionary YAML validation as an Oclip command?

Run Oclip and execute a command:

Command

oclip --product onap-honolulu dictionary-validate --yaml <path-to-yaml-file>

For example

vnfadmin@ddc559540515:/tmp$ oclip --product onap-honolulu dictionary-validate --yaml /tmp/Simple_Valid_Schema.yaml
{"file":"/tmp/Simple_Valid_Schema.yaml","date":"Mon Dec 28 07:38:43 UTC 2020","criteria":"PASS","errors":"[]"}

vnfadmin@ddc559540515:/tmp$ oclip --product onap-honolulu dictionary-validate --yaml /tmp/Dictionary.yaml
{"file":"/tmp/Dictionary.yaml","date":"Mon Dec 28 07:38:08 UTC 2020","criteria":"FAILED","errors":"
[{\"yamlDocumentNumber\":1,\"path\":\"/MetaData/Fields/measResultType\",
\"message\":\"Value(s) is/are not in array of accepted values.\\n value(s):  integer\\n  accepted value(s):
[float, uint32, uint64]\"},{\"yamlDocumentNumber\":1,\"path\":\"/MetaData/Fields/\",\"message\":\"Key not found: measChangeType\"},
{\"yamlDocumentNumber\":2,\"path\":\"/MetaData/Fields/\",\"message\":\"Key not found: measChangeType\"},
{\"yamlDocumentNumber\":3,\"path\":\"/MetaData/Fields/measAdditionalFields/vendorField1\",
\"message\":\"Value(s) is/are not in array of accepted values.\\n value(s):  [Z, A]\\n  accepted value(s):  [X, Y, Z]\"}]"}

VNF SDK OOM Installation

Prerequisite

All operations must be executed at RKE - log in at RKE.

How to install VNF SDK with ONAP from OOM:

1. Uninstall all components

helm undeploy dev –purge

TIP: Operation takes about 30-60 minutes. Please wait until it ends.

2. Clear all what have left

Execute below command:

for resource in deployment statefulset job pod pvc pv; do kubectl -n onap delete $resource –all –force –grace-period=0 & done

cd /dockerdata-nfs/dev/ sudo rm -rf *

3. Remove namespace

kubectl delete namespace onap

4. After changes in component in directory oom/kubernetes execute:

make vnfsdk

NOTE: This folder is in /home/ubuntu folder If you need to change a refrepo image or do other modifications, you need to make changes in values.yaml. Mentioned file is in /home/ubuntu/oom/kubernetes/vnfsdk.

5. Then you have to make entire ONAP project

make onap -e SKIP_LINT=TRUE

6. Install ONAP on lab:

If there is file deploy-onap.sh in directory oom/kubernetes, pls execute below command.

./deploy-onap.sh

otherwise:

helm deploy dev local/onap –namespace onap -f onap/resources/overrides/onap-all.yaml -f ./openstack-30-elalto.yaml –timeout 1000s –verbose 2>&1 | tee ~/helm-installation-manual.log

How to update only VNF SDK component from OOM

1. Uninstall VNF SDK Component

helm undeploy dev-vnfsdk –purge

2. Clear all what have left

sudo rm -rf /dockerdata-nfs/dev/vnfsdk/

3. After changes in component in directory oom/kubernetes execute:

make vnfsdk

NOTE: This folder is in /home/ubuntu folder If you need to change a refrepo image or do other modifications, you need to make changes in values.yaml. Mentioned file is in /home/ubuntu/oom/kubernetes/vnfsdk.

4. Then you have to make entire ONAP project

make onap -e SKIP_LINT=TRUE

5. Install ONAP on lab

helm deploy dev-vnfsdk local/onap –namespace onap -f onap/resources/overrides/onap-all.yaml -f ./openstack-30-elalto.yaml –timeout 1000s –verbose 2>&1 | tee ~/helm-installation-manual.log

How to upgrade Refrepo in VNF SDK from OOM:

1. Edit Refrepo image in VNF SDK Ddeployment

kubectl -n onap edit deployment dev-vnfsdk

then change:

image: nexus.onap.dyn.nesc.nokia.net:10001/onap/vnfsdk/refrepo:1.6.0-STAGING-latest
imagePullPolicy: Always
name: vnfsdk

2. Check if VNF SDK works

curl –insecure -i -H “Accept: application/json” -H “Content-Type: application/json” -X GET https://WORKER_IP:REFREPO_PORT/onapapi/vnfsdk-marketplace/v1/vtp/scenarios

NOTE: To get information about REFREPO_PORT, pls execute:

kubectl -n onap get service | grep refrepo

3. Enter at vnfsdkmarketplace UI

In your browser go to: http://WORKER_IP:REFREPO_PORT/onapui/vnfmarket

Getting into VNF SDK pod

1. Enter the VNF SDK pod

kubectl -n onap exec -it <vnfsdk pod> /bin/bash

NOTE: To find <vnfsdk pod> execute: kubectl -n onap get pod | grep vnfsdk

2. To check logs go to /service/logs

cd /service/logs

and then you can see vnfsdkmarketplace logs executing:

cat vnfsdkmarketplace.log

or catalina logs executing:

cat catalina.out