This page will walk through the robot framework automated creation of the vFirewall Closed Loop (vFWCL) use case to show how the overall vFWCL works and to high light the confirmation steps and training that can be derived from the robot automated test.
Preconditions:
- The demonstration VNFs like vFWCL assume that the ONAP OAM network is setup in your environment as a 10.0.0.0/16 with a prefix cidr of 10.0. Robot will assign OAM IP addresses in this range.
- The demonstration VNF heat templates assume that the PUBLIC neutron network (openStackPublicNetId) provided in the robot section of the override.yaml / values.yaml chart is setup so that new interfaces can be created via the VNF Heat template on that public interface. It need not be an external public network and many environments use a separate external network with floating IPs to assign an external IP to the VNFs external facing ip address/ports after instantiation if they have that setup.
- ONAP has been installed
- robot init has been run ((e.g., ./demo-k8s.sh onap init)) to setup the customer , cloud configurations, distribution of models and set the owning entity/project/line of business in VID for tracking the Service and VNF
- Additionally a distribution should be run ( ./ete-k8s.sh onap healthdist) to confirm that model distribution succeeds
cd /root/onap/kubernetes/robot
./ete-k8s.sh onap health
./ete-k8s.sh onap healthdist
./demo-k8s.sh onap init
./demo-k8s.sh onap init_robot
The "init_robot" simply sets the password for the test account on the robot web page that we will be using.
http://<k8s-node-ip>:30209/logs/ is the page to see the robot test cases results and from there we will walk through the results.
Select one of the test cases from the list and then open log.html (e.g., http://<k8host-ip>:30209/logs/0005_ete_instantiateVFWCL/log.html )
TestsuitesTestLogvFWCL_Dublin.html
./ete-k8s.sh onap instantiateVFWCL
This one line will do all the steps required to instantiate and setup the Virtual Machines for closed loop control in about 20 minutes.
Either the instantiateVFWCL or the instantiateVFW can be used to confirm that your ONAP installation and configuration (particularly to Openstack) is correct.
This table will cover the important steps in the log.html file to highlight items of note during the test case.
NOTE: The important difference between robot's use of the SDC internal API's is that the service is created first and items are attached to the service. In the GUI , the items are attached to a temporary structure and then a service is created by dragging the resources from the pallette onto the service. The result is the same service and resource artifacts. References to ASDC are legacy tags that in the future will correctly be edited to be SDC.
| Description (Keyword) | Comment | |
|---|---|---|
| 1.0 | Setup Orchestrate VNF | These steps will pull data from openstack and create the data in A&AI if it does not exist for the tenant, region, network zone and complex. |
| Initialize Tenant From Openstack | Set the tenant_name and tenant_id | |
| Initialize Regions From Openstack | Get the regions | |
| Inventory the Region If Not Exists | For all regions (RegionOne) under the tenant check A&AI and creates them if they do not exist | |
| Inventory Zones If Not Exists | Checks A&AI for the network zone (zone1) and creates it if it does not exist | |
| Inventory Complex If Not Exists | Checks A&AI for the complex (clli1) and creates it if it does not exist | |
| 2.0 | Orchestrate the VNF | This will onboard the vendor software product (vFWCL) , create a service and distribute the service |
| Get the Region | ||
| Generate a unique Customer Name | ||
| Generate a unique Service Name | ||
| Model Distribution For Directory | This step will onboard the vendor software products (heat templates) in the directory requested which in this case is for the vFWCL (heat templates are from the ONAP demo repository. For vFWCL there are two v VNFs in the service. vFWSNK (vFW and traffic sink) and vFWPKG (a packet generator). The VES telemetry will come from the vFW and the control loop will modify the packet generator to control the traffic. These steps are start the process of the service designer role as "cs0008" | |
| vFWCL/vFWSNK → . Create Zip From Files In Directory | These steps will create a zip file with the .yaml, .env and the manifest from the vFWCL/vFWSNK directory | |
| vFWCL/vPKG → . Create Zip From Files In Directory | These steps will create a zip file with the .yaml, .env and the manifest from the vFWCL/vPKG directory | |
| Distribute Model From ASDC | This will start to use the zip files just created to onboard the vendor software product | |
| Add ASDC Catalog Service | Robot creates the service first to have a bucket in which to put artifacts. In the GUI , the service is created last. | |
| vFWSNK: Setup ASDC Catalog Resource | for each VNF robot will create a license | |
| Add ASDC License Model | ||
| Add ASDC License Group | ||
| Add ASDC Entitlement Pool | ||
| Add ASDC Feature Group | ||
| Add ASDC License Agreement | ||
| Submit ASDC License Model | With all the parts of the license added the license model is submitted. | |
| Add ASDC Software Product | The vendor software product meta data is created | |
| Upload ASDC Heat Package | The zip file is uploaded | |
| Validate ASDC Software Product | Ask SDC to parse the uploaded zip file | |
| Submit ASDC Software Product | Submit the vendor software product | |
| Package ASDC Software Product | ||
| Add ASDC Catalog Resource | Turn the vendor software product into a catalog resource | |
| Certify ASDC Catalog Resource | Make the catalog resource available for use in a service | |
| vFWCL_vPKG: | ||
| (repeat above steps from the vFWCL_vFWSNK) from Setup to Certify | ||
| Checkin ASDC Catalog Service | Since robot already created the service and attach the catalog resource to it we only need to checkin the catalog service so that it is available for testing, governance approval and distribution | |
| Request Certify ASDC Catalog Service | Last step by service designer (cs0008) | |
| Start Certify ASDC Catalog Service | Service tester role (jm0007) opens the service | |
| Certify ASDC Catalog Service | Service tester role certifies the service. | |
| . Approve ASDC Catalog Service | Governance role approves the service (gv0001) | |
| Distribute ASDC Catalog Service | Operations role distributes the service (op0001) | |
Distribution occurs to AAI, SDNC, SO and other components. | ||
| Loop Over Check Catalog Service Distributed | This will loop over the get Distribution Details and look for the results of SO to mark the distribution complete when AAI, SDNC and SO have indicated DEPLOY_OK and no other component has raised a DEPLOY_ERROR in teh watchdog timer interval (typcially 5 minutes) . VID queries AAI to see service in the DISTRIBUTION_COMPLETE_OK state in order to know to display the DEPLOY button. | |
| 3.0 | Instantiate the Service (this is not a keyword but a change from SDC onboarding to using VID | |
| Create Customer For VNF | This is the first step on the VID screen. Robot creates a unique customer for each run of the test case to avoid conflicts and to make it easier to find the VNFs created in this test case. Robot creates the customer in A&AI via the REST interface | |
| Login To VID GUI | Robot got to the VID GUI directly | |
| Select From List By Label (VNF-API) | This test case uses the original VNF-API. You have to select this on the VID Home Screen | |
| Create VID Service Instance (Wait for Success) | ||
| Go To VID HOME | This is the strating point for robot VID interactions (the selected VNF-API is remembered in VID for this session | |
| Go To VID Browse Service Models | The wait for is intended to handle delays in the model being available to VID from the AAI query for DISTRIBUTION_COMPLETE_OK models | |
| Filter on the service model name: FWCL 2019-06-24 15:49: | ||
| Wait Until Page Contains Element .. "DEPLOY' | ||
| Press Key ( Click on Deploy button) | The create service "Instance Name" screen should now come up | |
| Select From List When Enabled //select[@prompt='Select Subscriber Name'], | ||
| Select From List When Enabled //select[@prompt='Select Service Type'], | ||
| Select From List When Enabled //select[@prompt='Select Project Name'] | ||
| Select From List When Enabled //select[@prompt='Select Owning Entity'] | ||
| Input Text When Enabled, //input[@parameter-name='Instance Name'] |
| |
| Click on the Confirm button | VID will now submit the request to create the service to SO | |
| . Poll MSO Get Request |
| |
| Validate Service Instance | Query A&AI to make sure the service instance is created | |
| 3.1 | vFWCLvFWSNK | For each VNF in the service create the VNF and the VF Module |
| Create a unique VNF name | ||
| Create VID VNF | ||
| . Click Element button=Add node instance | Select the drop down of VNFs in the service | |
| Click Element xpath=//a[contains(text(), '${vnf_type}')] | Select the vFWCLvFWSNK VNF This will cause the Create VNF Dialog Box to pop up | |
| Input Text xpath=//input[@parameter-id='instanceName'] | ||
| Select From List By Label xpath=//select[@parameter-id='productFamily'], | ||
| Select From List By Label xpath=//select[@parameter-id='lcpRegion'], | ||
| Select From List By Label xpath=//select[@parameter-id='tenant'], | ||
| Click Element xpath=//multiselect[@parameter-id='lineOfBusiness'] | ||
| Select From List By Label xpath=//select[@parameter-id='platform'], | ||
| Click Element button=Confirm | This will cause VID to send the Create VNF Instance request to SO
| |
| Wait for Success and Close Dialog | ||
| Preload Vnf (SDNC) | Now that a VNF is created we can set the data that will be used for the VFModules keyed by VNF instance name. Robot will use the REST API into SDNC to insert the preload data. This is a POST to submit and a GET to confirm. | |
| Create VID VNF module (VID) | ||
| Wait for the Add VF Module button to be visible | ||
| Click Element xpath=//div[contains(.,'${vnf_name}')]/div/button[contains(.,'Add VF-Module')] | ||
| Click Element link=${vnf_type} | This will cause the Add VF Module dialog to appear | |
| Input Text xpath=//input[@parameter-id='instanceName'], | ||
| Select From List By Label xpath=//select[@parameter-id='lcpRegion'] | ||
| Select From List By Label xpath=//select[@parameter-id='tenant'] | ||
| Select Checkbox xpath=//input[@parameter-id='sdncPreload'] |
| |
| Click Element button=Confirm | This will cause VID to send the Create VF Module to SO. SO will query SDNC for preload and then call the Openstack API's to create the stack
| |
| . Poll MSO Get Request | this can take minutes based on when the Openstack heat engine returns success to SO | |
| . | The VNF should now exist | |
| Validate Generic VNF | Query A&AI to see artifacts that SO and SDNC have written | |
| Execute Heatbridge | This will query openstack and update A&AI with items like the dhcp addresses assigned to the VM's It also does a reverse update of AAI with openstack data. | |
| 3.2 | vFWCLvPKG : | |
repeat the above steps for the second VNF from: Create a unique VNF name to Execute Heatbridge |
| |
| 4.0 | Update vVFWCL Policy | This will create and push the control loop policy to the DROOLS engine in policy |
| Create vFirewall Monitoring Policy | This is a future capability that is not effective since DCAE doesnt pickup this policy in Dublin | |
| Create vFirewall Operational Policy | The Control Loop Name is created and the resourceID inserted into the policy so that Policy can find the VNF data during its processing for control loops | |
| Push vFirewall Policies To PDP Group | ||
| Validate the vFWCL Policy | ||
| 5.0 | For each vfmodule that has a defined variable for the mount ${vf_module_name} = Vfmodule_Ete_vFWCLvPKG_c7fca777_1 has a vpg_name_0 variable (vFWSNK does not) | |
| Create the APPC Mount Point | Create the NETCONF mount point in APPC for closed loop control | |
| Get the IP address from Openstack | ||
| . Run APPC Put Request | ||
| <END> | The Virtual Machines and networks are created from the two heat stack, A&AI has been updated and marked the service as Active , the policy has been pushed and the APPC netconf mount has been created. The DCAE TCA Policy needs to be updated with the matching Control Loop Name from the Operation vFW Closed Loop operation testing can begin as soon as the VNF finishes its application install and configuration. Traffic should be visible on port 667 of the traffic sink VM. | |
3 Comments
Beejal Shah
Brian Freeman were you able to get vFW CL working in Dublin? We are able to instantiate but Policy is not triggering when TCA breach is detected.
Brian Freeman
Check the TCA ControlLoopName in DCAE/consul and update it to match the controlLoopName that robot created
https://gerrit.onap.org/r/#/c/integration/+/90102/
Added a script to update the TCA ControlLoopName but you can use the UI or Curl to do the same thing.
(http://<k8-ip>:30270/ui/#/dc1/kv/dcae-tca-analytics)
Here is a nicer description.
https://docs.onap.org/en/dublin/submodules/oom/offline-installer.git/docs/vFWCL-notes.html?highlight=tca
Step 7 (sub-step b is the one that actually makes the change)
Brian Freeman
Example of how to run the vfwclosedloop test from Robot after updating the TCA control loop policy name (courtesy of Gary Wu's jenkins job)
PKG_STACK=$(openstack stack list -f value -c "Stack Name" --sort creation_time:desc | grep Vfmodule_Demo_vFWCLvPKG | head -1)
PUBLIC_NET_ID=$(openstack stack show $STACK_NAME -f json | jq -r '.parameters.public_net_id')
PUBLIC_NET_NAME=$(openstack network show $PUBLIC_NET_ID -f value -c name)
PKG_IP=$(openstack stack resource show $PKG_STACK vpg_server_0 -f json | jq -r ".attributes.addresses.$PUBLIC_NET_NAME[0].addr")
/root/oom/kubernetes/robot/demo-k8s.sh onap vfwclosedloop $PKG_IP