Page Comparison

...

1. Add VES to your VNF
   1. Create a debian package of the VES client for DANOS using the VESreporting_vFW5.0_DANOS sub-directory from the demo repository
   2. The DANOS build process uses debian packages so this step is creating a VES reporting Debian client that can use the DANOS API's to retrieve statistics
   3. libevel.so must be built and bundled into the package since its not available on the ONAP artifact repositories as a debian package.
2. Create a Openstack Image
   1. Create a DANOS ISO image that includes the VES client
   2. This is following the existing DANOS procedures for building an  ISO from binaries and the procedures for creating an Openstack image
      1. Follow instructions in BUILD_DANOS.md in the demo repository which has slight changes from the DANOS tutorials.
      2. https://danosproject.atlassian.net/wiki/spaces/DAN/pages/491554/Creating+a+DANOS+ISO+using+binary+packages
      3. https://danosproject.atlassian.net/wiki/spaces/DAN/pages/79560705/Creating+a+DANOS+Virtual+Router+VNF+in+Openstack
   3. DANOS supports SNMP already but we want to use the vRouter as a replacement for the existing vFW which is VES based.
   4. DANOS could be used for both VES and SNMP based testing with the addition of this simplified VES client.
3. Create the heat template
   1. Create the heat template for DANOS under a new service vFWCLDN
   2. vFWCLDN is a short hand that makes naming of the VNFs fit within the string lengths in Openstack and ONAP.
   3. The full VNF will be the same packet generator and traffic sink as the standard vFWCL but use DANOS vRouter instead of the ONAP vFW
   4. The DANOS vRouter heat template is minimal.
4. Create the preload_data
   1. This will be the same data items as vFWCL but will demonstrate one of the steps to use for onboarding any VNF to ONAP's automated testing
5. Create the service mapping data
   1. This will add the pointers to the heat templates that are primarily just a name change from vFWCL to vFWCLDN so that the testing tools can map the service to the locations of the various artifacts
6. Add the QCOW2 image for your VNF to your glance repository
   1. Add the QCOW2 image for the DANOS with VES vRouter to your Openstack glance repository
7. Create the flavor for your VNF
   1. Create the flavor for the DANOS vRouter - 4 vcpu, 4 Gig ram, 8 GB disk with hw_options for cpu_model: passthrough
      
      1. cpu passthrough is the simplest way to ensure that SSSSE3 SSSE3 is exposed as a capability from in the virtualized hardware.
      2. hw:cpu_model = passthrough

Image Added

1. 1. Standard vFW is m1.medium but DANOS is a smaller footprint and an on disk image that is only 8 GB instead of a full Ubuntu volume.
2. Add a tag for running tests with your VNF
   1. Add instantiateVFWCLDN tag and data for an  instantiate VNF testcase  to demo.robot
   2. The command line "./ete-k8s.sh onap  instantiateVFWCLDN"  would now onboard the vFWCLDN models and instantiate the VNF as a DANOS vFW and a traffic sink and a traffic generator without having to use the GUI's directly so it could be used for regression.
3. Document any post instantiation steps
   1. DANOS Post Install Configuration
      1. Use curl/postman to make Netconf configuration changes to the vRouter to configure the ports - this demonstrates post instantiation configuration through SDNC
      2. Update the DACE collector ip addres and port in the vRouter if not provided on your VNF by cloud-init (also works for PNFs)
   2. Use horizon to remove the "Port Security" on the ports for the 3 virtual machines in case your version of openstack defaults to activate port security.
4. Test that the VNF works with ONAP
   1. Closed Loop telemetry from DANOS to DCAE/VES can be confirmed indicting both correct traffic flow from the packet generator to the traffic sink through the DANOS vRouter but also that VES telemetry is properly going to DCAE and being processed as events.

...