...

...

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	Contact 'Rajendra P Mishra (RP)' <rpmishra@aarnanetworks.com> to get access

Event Notes

Day 1 - Monday

• Participants: Lincoln Lavoie , Parker Berberian, Al Morton Ryan Hallahan Kanagaraj Manickam Ömer Zekvan YILMAZ  Huseyin Aydin Brandon Lo 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, Ömer Zekvan YILMAZ  Huseyin Aydin Brandon Lo, 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, Ömer Zekvan YILMAZ  Huseyin Aydin Brandon Lo, 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 , 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):

...