| Track | Key Points | Challenges | Next Steps / AIs |
|---|
| Testing | - CLI tests on Dublin working successfully; VNF vendors can/were able to run these to establish validation interop with ONAP
- Got an instance of ONAP from AT&T (at 5pm) to try as a second approach to testing
- Seem to have the HEAT VNF life-cycle tooling running on the lab ONAP instance as well (last failure was only a missing image in openstack).
| - Debugging of VNF test scripts is extremely challenging, logout, with most of the debugging relating to ONAP and not specifically the VNF on-boarding or running on the infrastructure.
| - Running the VNF tests on the AT&T infrastructure
- Going to try and do this tonight, while we have AT&T CA folks online
- Fix the missing image on the demo VNF
- Running the VNF participants VNF through the testing.
|
| CNTT | |
|
|
- Governance:
- (On-boarding, Adoption, Release cadence, trials, OPNFV Alignment).
|
|
|
| OPNFV | | OPNFV's motto has long been working upstream. The river analogy is taking new paths and reaching other communities, embracing the changing tides of OPNFV Technical Steering. | |
RA 2 Deep Dive - Mostly review of Ch3 issues, followed by text review in first AM slot.
|
| - Forward-looking discussion of Programmable Network Fabric (P4). Has certain advantages unproven - Performance and scalability, but seen as challenging the usual NF vendor model by requiring application code in Smart NICs and the Controller Point (split from User Plane).
|
CNTT | OPNFV Release & Lifecycle Planning - Ecosystem has shifted, OPNFV is refreshing and redefining what release artifacts will be
- Straw model mode of operation presented
- Chicken and Egg Problem →
| - RI1 is a good place to start as the processes are more mature and the upstream release cycles are better understood
- RI2 is going to be much more of a learning process as CNF is still a very volatile environment wrt changes
- So, which comes first? The RC or the RI? Can we release an RI without it having been certified?
| - Need to define release cadences, per stream (RI1, RI2)
|
CNTT RC Cookbook Description: - Leverages existing OPNFV CI/CD toolchain (jenkins) and test results DB
- Cookbook starts with Airship deployment, otherwise it is the same as RI
- Test tools conform to RA Ch5, when RI available, can add any form of additional benchmarking
- X-testing CI first creates a copy of the OPNFV CI in the local system
- RC specifies what tests MUST be run, Functest Implements the tests
| - There must be an exact record "Source of Truth" of what tests have been executed and the results.
- Also, how do we patch in a reasonable way: Controls on the file that determines the tests run are needed. Processes needed. Essential to build the BADGING process up (from where we are.
- Choices between Tools must be set by Policy == DETERMINISTIC
| - Trouble shooting needs to include Best Practices and General Guidelines, but also let the Community know (Open JIRA in Functest, or other tools) that something failed (more than log files from the failing test are needed). Need to open an issue for RC Appendix on Troubleshooting
- TSC must help find the PTLs of the necessary projects, but they haven't replied. Also need to discuss the related "level-up" to CNTT question at TSC and Weekly Tech Discuss (with PTLs).
- Need a real distinction between projects which are currently inactive but have responsible people available and projects that have working repos, but no support, (and should be closed). See https://wiki.opnfv.org/display/PROJ/Project+Directory
- CNTT RC has a list of projects they are looking at to fulfill their needs
|
| OPNFV 2.0 | Three big buckets of work: OPNFV mission refresh (which includes looking at the projects critically and make some hard decisions about projects that are outside the critical mission Increase CNTT/OPNFV interactions (some projects and members heavily engaged)
| Roadmap Development (Tactical now, multi-year next).
- Solicit SPC help in development
Action Items: (8 total) - Catch the Balls from CNTT through Sunset
- Plan OPNFV/CNTT Interactions
- TSC faster/stronger/more involved in project and release objectives.
- Focus on Adoption and why the Industry Should Care what OPNFV Accomplishes!
|
| ONAP | Collaboration between 3GPP (and other SDOs) and ONAP - - 3 GPP/SA5 Liaisons to
- TMF: many collaborations on API. TMF also launched various catalyst projects based on ONAP
| How to provide links to ONAP implementations from 3GPP (eg Github, RTD link) ? | 3GPP/SA5 collaboration to Establish more communication wit TMF to get more feedback on ONAP (via catalyst experience) Catalyst projects can be seen as use-case incubation |
ONAP Integration Gating retrospective ~2h to deploy ONAP Dashboard: <add link> Recap of KaaS (Kubernetes as a Service) POC to support Gating activities - deployment on Ms Azure | Avoid merge code when OOM gating is failing Need to identify how we can pursue footprint reduction effort | Sync-up with SO, OOM team to identify additional 'build' improvement Next focus on AAI
|
OVP Automation Augment with ONAP - urgently need to introduce automated testing tools to improve testing efficiency and solve problems in traditional testing
- Can leverage ONAP and OVP projects to build the automated testing pipeline
- ONAP and OVP gap analysis
- Suggestion for OVP: provide common testing platform， focus on process automation and provide integration capability to integrate with different tools from different upstream projects and vendors
- The efforts have been done
- NFV automation testing survey
| - lack of automated tools for NFV tseting
- ONAP and OVP project need to make up the gaps to achieve the automated testing
- OVP should avoid duplicate work between different upstream project and push automation
| need to work with OVP and ONAP to identify the real telecom testing requirements and push the related work in ovp and ONAP to make up the gaps |
| <Other sessions> |
| Listen to the Daily Hudles recording for the full report |
