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 Name | Contact | Resources Available | Notes |
---|
UNH-IOL | Lincoln Lavoie <lylavoie@iol.unh.edu> Parker Berberian <pberberian@iol.unh.edu> Brandon Lo <blo@iol.unh.edu> | - ONAP El Alto Instance
- OpenStack Instance
- 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
Lab#2 Resources
Lab Name | Contact | Resources Available | Notes |
---|
Lenovo-US | | - 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
|
| - ONAP Dublin instance
- 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 Name | Contact | Resources Available | Notes |
---|
LaaS | 'Rajendra P Mishra (RP)' <rpmishra@aarnanetworks.com> | - ONAP Dublin instance
- 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
- 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