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:

• @Lincoln Lavoie

• @Amar Kapadia

• @Pierre Lynch [Keysight]

Test Plan

• Test Plan

Testing Resources

Lab#1 Resources

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

UNH-IOL VPN Client File

Lab#2 Resources

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

Lab#3 Resources

Event Notes

Day 1 - Monday

• Participants: @Lincoln Lavoie , @Parker Berberian (Deactivated), @Al Morton @Ryan Hallahan @Kanag @Ömer Zekvan YILMAZ  @Huseyin Aydin @Brandon Lo (Deactivated) @Fahad Al Rhili

• Team 1:

  • Lead: Parker

  • Resource: UNH-IOL ONAP

  • VNF: 

• Team 2:

  • Lead: RP

  • Resource: Lenovo / Wind River ONAP

  • VNF: 

• Documentation:

  • Test Plan Document

  • How to run HEAT VNF test tools: https://wiki.onap.org/pages/viewpage.action?pageId=68546123

  • How to run TOSCA VNF test tools: https://wiki.onap.org/display/DW/OVP-VTP

• Notes:

  • Issue with ONAP talking to the OpenStack API on the UNH-IOL resource is partly solved.

    • API can be reached by the ONAP containers, but robot scripts are complaining the OpenStack API is using a self-signed certificate (http://132.177.253.66:30209/logs/0036_demo_init/log.html).

Day 2 - Tuesday

• Participants: @Lincoln Lavoie , @Parker Berberian (Deactivated), @Ömer Zekvan YILMAZ  @Huseyin Aydin @Brandon Lo (Deactivated), @Sumesh Malhotra @Fahad Al Rhili

• Since El Alto continues to not work, the team is recommending that VNF vendors test using manual testing https://onap.readthedocs.io/en/latest/submodules/vnfrqts/testcases.git/docs/OnboardInstantiateTests.html  

• See RP for CLI commands to run these manual tests

Day 3 - Wednesday

• Participants: @Lincoln Lavoie , @Parker Berberian (Deactivated), @Ömer Zekvan YILMAZ  @Huseyin Aydin @Brandon Lo (Deactivated), @Sumesh Malhotra @Fahad Al Rhili

• CLI tests on Dublin working successfully; VNF vendors can/were able to run these to establish validation interop with ONAP

• El Alto automated scripts still not available due to ONAP El Alto not being fully up (09:20AM)

Day 4 - Thursday

• Participants: @Parker Berberian (Deactivated) , @Lincoln Lavoie , @Brandon Lo (Deactivated), @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:

  • Discuss LFN Board Slides for Plugfest OVP VNF Hacking Track Sept 19v2.pptx

  • Discuss Webinar title

  • Discuss steps required to create the test plan

• Oct-25-2019

  • Test plan development

  • Follow up with webinar attendees

  • Weekly/bi-weekly call setu