Versions Compared

Old Version 6

changes.mady.by.user Hector Anapan-Lavalle

Saved on

compared with

New Version Current

changes.mady.by.user Hector Anapan-Lavalle

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Onboarding process flow of a VNF in ONAP


The following assumptions are made before following the steps of this wiki:

  • All components are deployed in an OpenStack environment.
  • ONAP (Beijing release) has already been deployed on a Kubernetes cluster with the required components listed below.
  • You can successfully access the Kubernetes cluster where ONAP is deployed at using the kubectl CLI.
  • While Rancher is the Kubernetes-based container management platform of choice for testing the steps below, it is not required and other Kubernetes orchestrators can be used (i.e. Cloudify)


The following ONAP components are the required ones to execute the vFirewall Closed Loop demo successfully:

...

...


Prepare the HEAT

...

Packages


In this part, we need to grab the HEAT templates above and do the following steps to popoulate the HEAT ENV file parameter values to prepare to upload them in the SDC Widget later on in this document.

...

Code Block
languagebash
themeEclipse
linenumberstrue
parameters:
  image_name: PUT THE VM IMAGE NAME HERE ( Suggested: UBUNTU 14.04 LTS - QCOW2 Format )
  flavor_name: PUT THE VM FLAVOR NAME HERE ( Suggested: OpenStack-standard m1.medium )
  public_net_id: PUT THE PUBLIC NETWORK ID HERE ( Provider-Type Network only - NO Floating IP Network )
  unprotected_private_net_id: zdfw1fwl01_unprotected ( Leave as is )
  unprotected_private_subnet_id: zdfw1fwl01_unprotected_sub ( Leave as is )
  unprotected_private_net_cidr: 192.168.10.0/24 ( Leave as is )
  onap_private_net_id: PUT THE ONAP PRIVATE NETWORK NAME / ID HERE
  onap_private_subnet_id: PUT THE ONAP PRIVATE NETWORK NAME / ID HERE
  onap_private_net_cidr: 10.0.0.0/16
  protected_private_net_cidr: 192.168.20.0/24
  vfw_private_ip_0: 192.168.10.100
  vpg_private_ip_0: 192.168.10.200
  vpg_private_ip_1: 10.0.100.2
  vsn_private_ip_0: 192.168.20.250
  vpg_name_0: zdfw1fwl01pgn01  ( Leave as is - dummy value to be changed by SO in demo )
  vnf_id: vPNG_Firewall_demo_app  ( Leave as is - dummy value to be changed by SO in demo )
  vf_module_id: vTrafficPNG  ( Leave as is - dummy value to be changed by SO in demo )
  repo_url_blob: https://nexus.onap.org/content/sites/raw ( Leave as is )
  repo_url_artifacts: https://nexus.onap.org/content/repositories/releases ( Leave as is )
  demo_artifacts_version: 1.2.1
  install_script_version: 1.2.1
  key_name: PUT THE KEYSTONE SSH NAME TO BE MAPPED TO THE VMs
  pub_key: PUT THE PUBLIC SSH KEY PORTION OF THE KEYSTONE SSH NAME TO BE MAPPED TO THE VMs
  cloud_env: PUT openstack OR rackspace HERE


Once the values that need to be filled out above, create two zip files containing the two HEAT packages we need to upload to the Portal SDC Widget in later steps.


Accessing the Portal GUI on your local browser (Kubernetes-based approach)


In order to setup your local machine to access the Portal Web GUI and continue with the steps of this documentation, please follow the instructions in Accessing ONAP Portal using OOM and a Kubernetes Cluster.

You should now be able to successfully view the Portal GUI Login page at http://portal.api.simpledemo.onap.org:8989/ONAPPORTAL/login.htm.

NOTE: It is recommended to access the Portal GUI through your browser's cookie-disabled window. In chrome, go on Incognito window with Ctrl + Shift + N. In Firefox, go on a Private window with Ctrl + Shift + P.


ONAP Portal Users and their Roles

As part of this demo, we will have to login to a number of different Portal user accounts in order to execute the appropriate flow to ultimately deploy the vFirewall VNFs into your OpenStack environment (NOTE: default password for all user accounts below is demo123456!)


Username

Role

Description
cs0008DESIGNERTakes care of creating all the SDC resources, uploading the HEAT template, distributing the VNFs, etc.)


demoSUPERUSER

This is the Administrator account that has access to actions that require admin rights. This is the user that will trigger the action to ultimately deploy the VF Module (actual VNF HEAT Template execution).

gv0001GOVERNOR
jm0007TESTERTakes care of running the tests for the VNF, and approving that tests were successful.
op0001OPERATOR



Creating the Vendor License Model


In this part, we will create a Vendor License Model that will be tied to the Virtual Service Product (VSP) representing the vFirewall VNF package. 

In a production VNF, every VNF vendor has a license mechanism that authorizes the use of the VNF in an environment. This includes license details and agreements that are between between this VNF vendor and the Service Provider that will ultimately deploy the VNF.

In this demo, we will create a VLM since it is a requirement to successfully onboard the VSP in your environment. The following are some details around the VLM, which will be executed in one way or another in later steps:

  • The vendor details have to always be provided as part of the VLM definitions, and such vendor only needs to be specified once.

  • In order to have a valid and functional VSP, a VLM needs to be mapped to it.

  • A single VLM can have multiple license agreements mapped to it.

  • VLM components that will need to be created are:
    • License Agreements:
    • Entitlement Pools:
    • Feature Groups:
    • License Key Groups: