| Track | Key Points | Challenges | Next Steps / AIs |
|---|
| Testing | - 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.
| - 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.
| - We (VNF participants) would like to continue debugging the testing next week (January 20-24), if the environments can be kept up.
- UNH-IOL environment will be kept up until at least 1/27/2020.
- 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.
|
| CNTT |
|
|
|
| OPNFV |
|
|
|
| ONAP | Cross-project AI Cooperation and Innovation | Network intelligence is ALL about DCAE or Close Loop in ONAP?
No | Need a focal point for both internal and external information exchange and efforts collaboration |
| ONAP Projects Lifecycle and Review Review the criteria associated to the lifecycle of a project from proposal, incubation, mature, Core and Archived, based on what we learned from other communities. Goal is to focus resources on most mature and adopted projects. | Discussions about security/vulnerability issues that are identified post-mortem (after project termination/archived) | Checklist for the PTLs is in progress Review will be performed as part of an architecture review outside the ONAP release cycle. |
| Release cadence in ONAP changes to a fixed cadence with three releases annually. The content of the releases is what is ready at the time of the releases. The proposal follows the same process as that used by other open source projects such as Openstack. | Formulate the process more fully. | Take the proposal to the TSC for approval. |
| + Additional 5G Slicing topics | - CSMF/NSMF Portal Design
- Involvment of Data Lake services in 5G World
- SO
|
|
