•  9 non functional requirements have been prioritized up to now by the ONAP TSC for Guilin, requesting support from companies who are submitting usecase/functional reqs. How can we implement additional non functional requirements?
• Partial solution will also been discussed as a Cross-Community topic at 2.30pm UTC on Monday June 22nd, 2020- Help Recruit more Developers to LFN Projects! 
• Architecture Component Views in Readthedocs planned on Wednesday June 24th, 2020 at 3pm UTC to align with swagger work

•  PTLs/Non functional reqs Owners on PTL call (6/29) to assess what can we agree with the project teams for Guilin either as additional TSC MUST Have and/or CI-Gating, etc.

Details regarding Non functional requirements REQ-379, REQ-380  - https://wiki.onap.org/display/DW/License+compliance

The list of "Base Image statistics" can be enhanced as long as the ONAP Community will maintain it.

•   Organize a TSC vote on the list of licenses that can be used within ONAP containers i.e. approved licenses means which once we agree to comply with, in terms of license terms for distribution in docker containers
•  PTLs to confirm the comments in Green regarding "Upstream dockers in ONAP Nexus Server" section
•  Define a list of approved base images
•  Do the license compliance process for all approved base images
•  Make sure that all components use only approved base images

•  PTLs/Integration on PTL call (6/29) to discuss how to release more often prior M4 (conditions, regression and healcheck ok, rollback procedure, etc.)

Reviewed current modeling activities and candidate modeling requirements for Guilin.

The following topics were also presented:

1 Modeling process

2 Policy model

3 Slicing model

4 CNF Inventory Modeling 

5 CNF ETSI modeling overview

6 Modeling of Geolocation information

Recording may be found at: LNF_June_vDTF-ONAP-_Modeling_Subcommittee.mp4

• The former Policy architecture will be deprecated in order to embrace the new Self-Serve Policy Architecture developed from Dublin to Frankfurt.
• Presentation of the major Policy Guilin requirements including E2E Network Slicing, 5G OOF SON and improvements
• Policy team is in the process of creating Tutorials for the ONAP community to view to understand how to use the Policy Platform

•  Any volunteer to flesh out these ideas
•  How to implement in each LFN Open Community?

›How can we release more frequently, smaller scope without impacting the SW quality?

›How can we change the waterfall-ish development model?

›How can we get enough details about candidates requirements prior the release?

›How to manage the release in case of people turn-over?

›How to handle the scope and maintain a balance between Usecase/Functional reqs (attractive) and Non functional reqs (less sexy)?

•   Identify a set of projects that could prototype the Release Train approach
•  

   “Release cadence transition proposal” on June 25th, 2020 @ 11am UTC

•   Alignment with CNTT/CNCF TUG and O-RAN/ONAP in order to define their role as part of XGVela and identify what can be leveraged from the existing projects
•  Introduction of XGVela to the TAC team

Track: Cloud Native in Telecom Cloud

Presenters/Moderators: Qihui Zhao, Ying Li

•  Alignment with CNTT/CNCF TUG and O-RAN/ONAP in order to define their role as part of XGVela and identify what can be leveraged from the existing projects
•  Introduction of XGVela to the TAC team

Reviewed mandatory upgrades to Java 11 and Python 3 for all projects

Migration of ONAP to standard infrastructure versions: Docker, Kubernetes, OS images, databases, etc (see Database, Java, Python, Docker, Kubernetes, and Image Versions)

Updating vulnerable direct dependencies:

• SECCOM repo specific recommendations on the Security Vulnerabilities protected wiki space
• Must be complete by M2

Resources to do the non-functional work

Potential dependencies that conflict with new versions

SECCOM will have representative at the weekly PTL call to answer questions

PTLS and others are always welcome to attend the SECCOM weekly on Tuesdays to raise issues

PTLs secure resources and plan to identify show stoppers as soon as possible (M1)

EUAG Operator Survey & In-Depth Analysis On Consumption Model

Presenters: Atul Purohit

• EUAG should create an action plan out of survey inference, what it means for various committees and how can the feedback be provided back to CSPs
• Survey sample was about 50% of overall members and 75% of active members, to make similar activities more impactful in future perhaps the survey can be done with larger sample size

OOM Status update: what's planned internally

Presenters/Moderators: Sylvain Desbureaux, Krzysztof Opasiak

Review of the planned OOM changes :

Support of Helm V3

Kubernetes V1.17 (or 1.18)

Migrate to Seccom recommended Versions

Update defaults (use Ingress, Storage Class, Hardened OS)

OOM Status update: consequences on other components

Presenters/Moderators: Sylvain Desbureaux, Krzysztof Opasiak

Review of the required changes on components helm charts VS requirements

presentation of changes, use of templates, adding appender to Logback to support STDOUT as additional output

Container that do not contain ONAP code should not be hosted on Nexus

No Root access to DB

Application config should be fully prepared before starting the container

Containers must crash properly when a failure occurs

No more Nodeports

AAF optional (component should work without AAF even in degraded mode)

HTTPS is mandatory but should be configurable (disable in case of Service Mesh as this will be offloaded to Service Mesh)

Container RootFS should be mounted as ReadOnly

Commit message rules for OOM

Requirements Traceability:  Initial Request through TSC Approval

Presenters/Moderators: Alla Goldner, Chaker Al-Hakim, Pawel Pawlak, Pamela Dragosh, David McBride, Catherine Lefevre

• brainstorming and discussion on aligning the ONAP requirements pipeline 
• Consensus:
  • any requirements- regardless of source- should go through the requirements subcommittee.
  • and euag submits requirements to req. sub where they are vetted
  • committee consolidates backlog
  • committee should make prioritization recommendations to the TSC

wiki: 2020 June vDTF ONAP Requirements Traceability: Initial Request through TSC Approval

• How can we streamline the requirements coming from different sources inside and outside from the ONAP Community?
• As an example, EUAG → REq Subcommittee prioritirised → (Architecture Review) → TSC 

• Enhance the mission of the Requirements Subcommittee:
  
  • Act as the ONAP Product Owners 
  • Recommend Prioritization to the TSC
  • Create the consolidated ONAP Backlog

The presentation covers Frankfurt CNF instantiation improvements on vFW use case example

• Changed modelling of the vFW CNF - split into 4 helm packages to benefit from CDS resource assignment
• Change from a'la Carte VNF-API instantiation flow into Macro GR-API with CDS
• Utilization of CDS for automatic assignment of Helm package overrides
• CDS uploads optionally profile which allows for further helm enrichment like extra k8s resources

Use Case Doc: https://onap-doc.readthedocs.io/projects/onap-integration/en/latest/docs_vFW_CNF_CDS.html#docs-vfw-cnf-cds

Notes: 2020 June vDTF ONAP vFW CNF use case evolution

• We lack of the use case automation scripts, however, there is very good documentation + postman collection
• We leverage VNF flow in SO and still, we need to use dummy heat templates in the onboarding package
• vFW use case requires dedicated k8s cluster with virtlet, ovn4k8s and multus
• Data in AAI is still not synchronized with k8s
• Status of instantiated resources is not monitored by SO and

• vFW CNF Use case automation with robot scripts and use of modern VID UI
• Support of Close Loop
• https://jira.onap.org/browse/REQ-341 - CNF SO orchestration Enhancements
• Potentially new use case: VNF + CNF Heterogeneous service and/or pure CNF (without a need of specific k8s cluster setup)

• Did use SDC and MultiCloud K8S plugin, but did not use SO.  Did have one manual step.
• Container image was in a local K8S repository, not bundled in the service package

• Add handling for the macro flow
• migrate onap_tests repository to pythonsdk_tests
• Add close loop examples coming in next versions

Release more frequently VS time

•  Move to a more continous approach
•  Release at each milestone ? with working small steps
•  At RC0 provide %age completed, which ones are not done yet?

The code (as demonstrated) along with test scripts and swagger documents will be added to the multicloud/k8s repository soon.

https://github.com/onap/multicloud-k8s

• Continue discussion in CVC.
• Map 4-tier structure to CNTT.

• Interesting and detailed presentation by Ying Li and Shasha Guo of SDN implementations for several use cases like Traffic Mirroring and Routing Configuration, showing code snipets, network diagrams and parameter mappings

• Presentation on CNTT OpenStack Release selection by Pankaj Goyal et al, and second half by Shasha Guo on Cyborg Acceleration Mgmt.
• OSTK Pike was selected in Paris, but the next version was selected by a formal process and against defined criteria, the process started at Baldy vF2F in April 2020.  Train met the selection criteria and is recommended as the next CNTT OSTK version. Recommendation: utilize Ussuri OSTK release for Cyborg API v2.0 service (as it is incompatible with Train). Upstream: Cyborg should fix their API in Train release as per OpenStack policy.
• Discussion whether CNTT should jump straight to Ussuri to avoid back porting problems for Cyborg. An option for consideration for TSC (the only criterion not met by Ussuri is 6+ month requirement)
• Shasha Guo and Ying Li on Cyborg acceleration: presented scenarios why we need to use Cyborg, and Cyborg enhancement requirements for CNTT.

ODL Micro Status & Next Steps

• Slide Deck here - https://docs.google.com/presentation/d/1hqN9cFzmzkafCPgcEx7wZFB-rPaWHvKOBitcElNUYwk/edit?usp=sharing
• Need performance tests that show the improvement by ODL-Micro v/s OSGi/karaf
• Need performance data about how much percent improvement ODL-Micro gives when testing with a device

•  Tejas Nevrekarto share performance reports once available. Further elaboration in TWS once code is uploaded

ODL Platform API Changes and impact to downstream consumers

•  Follow-up is required to define the next steps

• Modelling og the CNF data
• So far VNF model will be used with slight modification required to track status of instantiated k8s resources
• 7 components impacted, required cooridnation effort

•  The implementation for Guilin will introduce first production level solution for CNF
•  It will open further changed for deeper integration of ONAP with CNFs fir Day2 configuration purpose or close loop support
  

• • Michela Bevilacqua : How to update a control loop instance?
  • Scott Blandford : We've put together a model for simplistic control loops. How do we deal with CL's that are stringing multiple DCAE together? Or have multiple interactions? How to monitor?
  • Pamela Dragosh : Monitoring tools may not be enough? Gervais-Martial Ngueko CLAMP monitoring is only capturing Dmaap events. Need much more development to support DevOps
  • Vijay Venkatesh Kumar : Discussion to support multi-tenant, how would control loops work in that architecture? How does a distributed deployment play out?

Track: Guilin Release - TSC Prioritization

Presenters/Moderators: Catherine Lefèvre and ONAP TSC

•  Prepare our Release Commitments before July 9th, 2020

• Publishing of robotframework-onapsdk library
• Extending ONAP wiki pages about Robot with reusable examples
• Publishing „create your own Robot library” template in python

Track: Set up Kubernetes ENV guide in Ubuntu

Presenters/Moderators:

Service Mesh PoC will require just few changes on the component:

• add an option to disable AAF integration on user management part if any
• add an option to disable HTTPs
• retrieve header and pass them if they are doing subrequest

• Retrieve all component clients (sdc distribution clients, dmaap clients, ...) and make them service mesh aware (pass headers in particular)

Developing PoC in R7

See MD C&PS PoC Slides at https://wiki.onap.org/pages/viewpage.action?pageId=81406119

Model Driven Configuration and Persistency Service PoC Deep Dive

Presenter: Tony Finnerty

•  Can we re-use / extend existing Yang Parser in SDC?
•  Can we use Yoghurt framework for Yang (de-)Serialization to maps?

• migrations not at all synchronized with the release schedules
• migrations mis-execution affects every project
• python version forced to 3.5  obsoleted after only 2 months during the Sodium SR2 release. When possible, lfn-tools must support several versions of python and not impose it.
• migrations are not automated. This also results in unexpected referencing problems for potential new contributors

• more transparency on LFN infra migrations - can be achieved with more non-LFN contributors
• TSC should be able to block LFN migrations
• control-loop between users / TSC and TAC/LFN

ODL BGPCEP Magnesium Retrospective and Roadmap for Aluminium

RFC 5440 support

Growth the community

Next challenge for the project

ODL Service Automation Framework (SAF)

ODL Platform Aluminum updates and Silicon lookahead

• How to make sure requirements in the newly created project are taken from CNTT.

• More discussion in RI-2 Calls to advance progress.

• Align all efforts to a single outcome and agree on one way of doing it.

• CNTT/OPNFV Releases Sync 

• Status on RA-1 security
• Evolution planed for Baraque release
• For security  testing, tests and tools available

• Expand RA-1 security chapter on system hardening, image security, monitoring and audit
• Review RM requirements, rephrase requirements not testable or too genric
• Continue the analysis of ONAP requirements relevant for CNTT

• The challenge will be the integration of the identified security tests for automated testing.

• Need quotes for new machines at UNH - IOL and Oregon
• INFRA is working with various projects to transition to Lab As A Service, rather than Static assignments.
• CI/CD Evolution Options - OPNFV is different from other LFN projects (but needs update?)
  • Migration plan includes a Proof of Concept phase
• Lab As A Service review - booking for various LFN projects. Look around at site: labs.lfnetworking.org
  • LaaS New Features - PTLs can define complete HW configuration, network configuration, merge configuration
  • LaaS Quick booking Improvements
  • Plus CNTT-ready! additional requirements for networking: greater uplinks, and additional storage
  • Anyone with LFID can use
  • New features planned: booking transfers between users, analytics dashboard, Jenkins integration

• Project Release Plans Template - Each project will describe and document their Artifacts/Deliverables
  
  • OPNFV's project plans have varied in degree of detail
• OPNFV TSC has the responsibility to establish the Release Process
• Requirements Vetting is still a sticking point
  • Release requirments are part of OPNFV Release process. Full Stop
• Requirments will come from CNTT, AND Openstack, ETSI NFV, and OPNFV participants.
• There are already LOTS of requirments to Vet that intend to be part of OPNFV's next release.

•  Follow-up is required to define the next steps