...

• 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), 
• 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):

...