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

« Previous Version 15 Next »

Define a Vendor Virtual Software Product (VSP)

At this point, we can proceed to define our vendor virtual software product. Hover over the "Add" box in the Onboarding Catalog and click on "New Vendor Virtual Software Product":

In the form that comes up, give the new software product a name of your choosing, and from the "Vendor" list, select the licensing model we created in the first part of this tutorial.

For "Category", select "Firewall (Application L4+)", as shown. Enter any description, and then click "Save".

The software product will be added to the Onboarding Catalog, and the product details page will be displayed. Click on the "Warning" icon under "License Agreement", in the section to the left.

On the resulting page (which can be reached from the "General" link in the left-hand sidebar), select the appropriate version of the license:

Select the license agreement.

When those two parameters have been set, a "Feature Groups" selector will appear. Choose the appropriate feature group.

Save the information you've entered so far by clicking on the "disk" icon toward the upper right of the page. DOC-3 - Getting issue details... STATUS Do NOT "Check In"!

Now, we can upload the ZIP file containing the Heat templates and scripts that describe our product. Click on "Overview" to return to the main page for the product we're creating. Click on the "Select File" button in the right-hand section of the page (or drag and drop your zip file). The zip file we're using for this tutorial is vFW 14.2.17.zip in the reference page, which can be obtained from the Reference Documents page.

Editing the base_vfw.env environment file for the virtual FW

in the following "1.0.0 template" - the identifiers highlighted should be modified from their original template.

parameters:

  vfw_image_name: Ubuntu 14.04 LTS (Trusty Tahr) (PVHVM)

  vfw_flavor_name: 4 GB General Purpose v1

  public_net_id: 00000000-0000-0000-0000-000000000000

  unprotected_private_net_id: zdfwfwl01_unprotected

  protected_private_net_id: zdfwfwl01_protected

  ecomp_private_net_id: c69b2c8e-bb65-427f-ba7b-695fb62bba39

  ecomp_private_subnet_id: cc0fbfdf-6217-4c6f-8d6b-e199d74504e4

  unprotected_private_net_cidr: 192.168.10.0/24

  protected_private_net_cidr: 192.168.20.0/24

  ecomp_private_net_cidr: 10.0.0.0/8

  vfw_private_ip_0: 192.168.10.100

  vfw_private_ip_1: 192.168.20.100

  vfw_private_ip_2: 10.1.0.1

  vpg_private_ip_0: 192.168.10.200

  vpg_private_ip_1: 10.1.0.2

  vsn_private_ip_0: 192.168.20.250

  vsn_private_ip_1: 10.1.0.3

  vfw_name_0: zdfwfwl01fwl01

  vpg_name_0: zdfwfwl01pgn01

  vsn_name_0: zdfwfwl01snk01

  vnf_id: vFirewall_demo_app

  vf_module_id: vFirewall

  webserver_ip: 162.242.254.138 # unused

  dcae_collector_ip: 10.0.4.1 # the private IP of the DCAE_Controller

  dcae_collector_port: 8080

  repo_url: https://ecomp-nexus:8443/repository/raw/org.openecomp.simpledemo

  repo_user: ecomp_os

  repo_passwd: peg64suk

  key_name: vfw_key

  pub_key: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDQXYJYYi3/OUZXUiCYWdtc7K0m5C0dJKVxPG0eI8EWZrEHYdfYe6WoTSDJCww+1qlBSpA5ac/Ba4Wn9vh+lR1vtUKkyIC/nrYb90ReUd385Glkgzrfh5HdR5y5S2cL/Frh86lAn9r6b3iWTJD8wBwXFyoe1S2nMTOIuG4RPNvfmyCTYVh8XTCCE8HPvh3xv2r4egawG1P4Q4UDwk+hDBXThY2KS8M5/8EMyxHV0ImpLbpYCTBA6KYDIRtqmgS6iKyy8v2D1aSY5mc9J0T5t9S2Gv+VZQNWQDDKNFnxqYaAo1uEoq/i1q63XC5AD3ckXb2VT6dp23BQMdDfbHyUWfJN marcoplatania@mt-asa1-1-vpn239.research.att.com


This vFW example is hardcoded to the EAST coast IAD region - to use the DFW region we should be able adjust the env file - see  DOC-6 - Getting issue details... STATUS

TODO:20170517: actually the vFW zip in the reference page states it is "old not for use" since 5 May - we will need to verify which of the 3 sets of yaml/env pairs are valid (zip contains base_vfw but I would expect we should be running base_vfw_rackspace under \demo\heat\vFW



The Heat template and environment file will be processed by SDC and a page showing the contents of the uploaded zip file will be displayed. The warnings in the right panel can be ignored. This page can be reached from the "Attachments" link in the left sidebar.

Now, we can "Check In", and then "Submit" our software product. If no problems are encountered, an alert showing the the product has been successfully submitted will be briefly displayed.

Define a New Virtual Function (VF)

Next, we need to return to the SDC home screen to create a new virtual function (VF) based on the virtual software product (VSP) we just created. Hover over the arrow to the right of "Onboard" in the bread crumb trail; a menu will appear. Select "Home".

Note the "Vendor Software Product Repository" icon in the upper right corner of the SDC "Home" screen. Click on it.

A form showing the various products in the repository will appear.

Select the product we created, and click the "Import VSP" icon to the right of the descriptive line that appears when the product is selected.

The "General" page for our new VF will be displayed. Click on "Create".

The VF will be created, which can take some time, depending on its complexity.

Once this process has completed, an alert will tell you that the new VF is now available. Note that the various elements in the left sidebar, which were previously disabled, are now all enabled.

On the "Icon" page, we can select an icon to represent our VF — the icons shown are based on the "Category" we selected earlier; we'll click on the "Firewall" icon to select it.

Click on "Deployment Artifact" to generate/update and display the deployment configurations.

The "Information Artifact" page can be used to attach a variety of different data and metadata to the VF.

The "TOSCA Artifacts" page shows the TOSCA orchestration information generated by SDC from the VF's specifications.

Data properties can be added to the VF on the "Properties" page.

New properties can be added by clicking on the "Add Property" link which brings up a specification form. A wide variety of property types are pre-defined.  We will not be adding a "Property" here.

Clicking on left pane "Composition" under "Properties" takes us into the actual Design Studio, where a graphical representation of our underlying VSP is shown on the canvas. To return to the VF specification, click on "VF: tutorial firewall" in the bread crumbs above the canvas.

The "Activity Log" page tracks all changes to the VF.

The "Deployment" page shows the resources related to the deployment of the VF, and a variety of information can be inspected from here.

Finally, the "Inputs" page show the parameters used to set up the VF. Details can be viewed by clicking on the various disclosure arrows.

At this point, our new VF needs to be submitted for testing as part of the ONAP workflow. Do not check in the VF at this point, simply click on "Submit For Testing".

A form will appear, prompting you for a message to the test team. Enter one and click "Save".

You will be returned to the SDC Home screen, where our VF now shows as being "Ready for testing".


  • No labels