• 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.

• Technical Tracks:
  • RA-1
  • RA-2
  • RC
  • RI

• Governance:
  • (On-boarding, Adoption, Release cadence, trials, OPNFV Alignment).

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

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!

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

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

O-RAN / OSC rel A / ONAP joint PoC/PlugFest results and next steps 

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