...
| Lab Name | Contact | Resources Available | Notes |
|---|---|---|---|
| Lenovo-US |
|
| |
|
|
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> |
|
|
...
- Participants: Parker Berberian , Lincoln Lavoie , Brandon Lo, Sumesh Malhotra, Ömer Zekvan YILMAZ , Huseyin Aydin
- 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.
...