Overview

To get VNF vendors more comfortable with the OVP program for VNFs, the plan is to conduct a OVP VNF hacking track at the Jan 2020 LFN Developer and Testing Forum in Prague. This can hopefully start a virtuous cycle where more VNF vendors means more ONAP in production, which in-turn will drive more VNF vendors to interoperate with ONAP.

The broad tasks are:

  • VNF vendor outreach – messaging, EUAG/MAC assistance, webinar, blog
  • Test plan creation – test plan for VNF vendors 
  • Pre-testing – Make ONAP environments available 6 weeks before the event for VNF vendors to do pre-testing before they come to the event
  • VNF hacking track – Onsite phase where vendors are free to do as little or as much testing as they feel comfortable with easy access to experts

Lead Volunteers:

Test Plan

Testing Resources

Lab#1 Resources

The following labs have committed resources to support  the hacking track.  

Lab NameContactResources AvailableNotes
UNH-IOL

Lincoln Lavoie <lylavoie@iol.unh.edu>

Parker Berberian <pberberian@iol.unh.edu>

Brandon Lo  <blo@iol.unh.edu>

  1. ONAP El Alto Instance 
  2. OpenStack Instance
  3. Lab as a Service (https://labs.lfnetworking.org)
  • Open Stack Details:
    • Version: 3.16.2 (Rocky)
    • Capacity (remaining beyond ONAP): ~40vCPUs, ~64gb ram
    • Horizon Dashboard: 192.168.122.220 (need VPN, admin / opnfv-secret-password)
  • ONAP El Alto 
  • VPN Access: OpenVPN 

  • NF Upload: Either through the VPN connection, or by "pulling" them from the Internet into the instance

  • Hosting sVNFM/EMS: Depending on the size, it should be possible to install this on the UNH-IOL OpenStack cloud


UNH-IOL VPN Client File

laas_opnfv.ovpn

Lab#2 Resources

Lab NameContactResources AvailableNotes
Lenovo-US

Anand Gorti

Eddy Raineri 

Stephen Gooch

  1. Lenovo NFVi + Wind River Titanium Cloud VIM (refer OPNFV Verification Program - NFVI Portal)
  • HW details
    • Lenovo ThinkSystem SR630/SR650 servers
    • Lenovo ThinkSystem NE2572/NE0152T switches 
  • VPN Access: Cisco AnyConnect  
  • Wind River Titanium Cloud (OpenStack) details
    • Jumphost IP: 10.240.71.171 (need VPN access)
    • Controller IP: 172.22.27.9 (accessible through Jumphost)
    • Keystone v3 required
    • Contact Eddy Raineri 

Anand Gorti

Amar Kapadia

'Rajendra P Mishra (RP)' <rpmishra@aarnanetworks.com>

  1. ONAP Dublin instance
  2. OpenStack instance 
  • HW details
    • Lenovo ThinkSystem SR650 servers
    • Lenovo ThinkSystem NE2572/NE0152T switches 
  • Aarna Networks ONAP Distribution (ANOD)

Note: The Lenovo lab resources will be available for testing to continue until  Jan 31st.

Lab#3 Resources

Lab NameContactResources AvailableNotes
LaaS'Rajendra P Mishra (RP)' <rpmishra@aarnanetworks.com>
  1. ONAP Dublin instance
  2. OpenStack instance


Event Notes

Day 1 - Monday

Day 2 - Tuesday

Day 3 - Wednesday

Day 4 - Thursday

  • Participants: Parker Berberian , Lincoln Lavoie , Brandon Lo, Sumesh Malhotra, Ömer Zekvan YILMAZ , Huseyin Aydin Fahad Al Rhili
  • Accomplishments
    • Got ONAP VVP testing (OOM Robot) running on two platforms.
    • Worked on running testing on 3 commercial VNFs through these systems.
    • Onboarded one of the VNFs through ONAP Dublin release.
    • VNF static (template) validation is passing on all 3 VNFs.
  • Challenges
    • OPNFV XCI OpenStack setup provides HTTPS for OpenStack API by default, using self-signed certificates. Within ONAP, this requires adding the self-signed CA to multiple pods. Should a step be added to the documentation / installed to allow a CA to be imported as part of the process?
    • During ONAP deploy, the authentication keys should have been stored within correct formats for SO / Robot / etc. However, this seems to have failed during the install and required manual correction.
    • Repeatedly running e.g. the robot scripts while debugging can leak state into ONAP that requires manually cleaning databases. The option to rollback changes or having a “wipe clean” script for A&AI would be very useful.
    • Initialization of values for ONAP (i.e. subscriber, cloudowner, line of business, etc.) isn’t clearly defined in the process, and if / who is responsible for setting those values. For example “demo-k8s.sh onap init” will setup / provide one set of values, while the “instantiate-k8s.sh” for the VVP testing may
    • assume a different set of values. It’s unclear in the documentation if VVP tooling would create these values if they aren’t yet existing in ONAP.
    • VVP Validation false passed in the case where the vnf-details.json had a mismatch to the file name for the module preload file name.
    • Two entry points for testing VNFs, based on VNF template types can be confusing to the users.
    • Robot VVP script failures had to wait for timeout (i.e. script stopped) before logs became available to debug the issue.
    • Need to get some support from community to provide TOSCA based VNFs to run through the testing process.
  • Next Steps
    • We (VNF participants) would like to continue debugging the testing next week (January 20-24), if the environments can be kept up.
    • For next DTF event, look into sending a weekly “briefing” email to all currently registered participants to point them to updated / latest resources, etc. This could also let them know about plugfest planning calls, etc. Need to have at least one pre-event call specific to the plugfest, to make sure resources are aligned, etc.

Past Activities

High-level status (chronological):

  • August-26-2019: CVC green signal to proceed. View presentation.
  • August-30-2019: Goal is to agree on the messaging. Proposed draft:
    • ONAP overview
    • ONAP xNF requirements
      • Direct/Heat approach
      • sVNFM/TOSCA approach
    • OVP overview
      • CNTT reference
    • Why is it important for VNF vendors to get involved with OVP – As operators move to common requirements, it is important for VNF vendors to be in sync with it, and VNF vendors need to be prepared for it
    • OVP VNF hacking track at the next LFN DDF/Plugfest details (CNF, PNF outside the scope of this event)
      • Rules of engagement – individual results will not be public. This is a safe zone. Amar to check with David McBride on the Plugfest rules.
      • Opportunity for VNF vendors to provide feedback on OVP to make it a better program.
      • Help & support available through 6 week pre-testing phase and at the event
    • Call-to-action: Invitation to attend Plugfest
  • August-30-2019: 
    • Use CNTT event to market to VNF vendors, Rabi to connect Amar to the right person
  • Sept-13-2019:
  • Oct-25-2019
    • Test plan development
    • Follow up with webinar attendees
    • Weekly/bi-weekly call setu
  • No labels