Project as part of CCSDK ( Yuriy Malakov  )

•  ACTION: Sandeep Shah Presentation of new architecture with CCSDK (Yuriy Malakov ). How much bandwidth/capacity does Sandeep Shah have.
  
•  ACTION: Development demo & progress (1) ORAN Yang models & data schema not available yet (waiting) & 5G Service Modeling U/C: 3GPP TS28.541/TS28.540. maps to a data structure we want to support. (2) can proceed to Dockerize solution. R4 MariaDB solution. could extend the model. (3) Review work from Ted. waiting for project.
  
•  ACTION: Give RC0 status - Sandeep Shah on RC0 status. Set up call with Sandeep Shah
  

Read the Docs

•  ACTION: Update ReadtheDocs https://git.onap.org/integration/tree/docs - Jira under Integration - invite team for review - invite PTL (Morgan R.) -Gerrit PTL submission +1 from reviewers. committer/Morgan +2 (someone in Integration project will do the Merge)
•  New project → Repo → DOC directory (RST) in that Repo Andreas Geißler  → Signoff for R6 May 2020; M0 for R7. If we are approved by TSC as a new project → create a new Repo

RunTime Config DB Project Proposal (Oct 25 2019)

•  ACTION: PERFORMANCE - Open (#@#) open items to get ballpark figures for # API requests.
•  ACTION: LIFECYCLE - find out the Lifecycle State "enumerations" - is "incubation" right?
•  ACTION: TSC Step #2 - Ben sent the TSC asking for slot. 26 Mar 2020 TSC. M4. RC0 bumped by a week. Q1 Who will be contributors. Joanne → Catherine.
•  ACTION: Virtual Meeting - What is our deadline? April 21-23. Subcommittee meeting (LA USA). planning virtual plannig / presentations. M0 wiki: https://wiki.lfnetworking.org/display/LN/2020+April+Virtual+Technical+Event
•  ACTION: Peer Review Process Step #1 - ONAP Projects ... Ready for PEER REVIEW? What is involved in that? What's the process? submit to the TSC? Ask Kenny what is PEER REVIEW? Presentation to ARCH S/C
•  ACTION: ID PTL/Contributors - who will be contributors, who wants to be the PTL. Resources & Committers from Ericsson (Tony Finnerty), AT&T, IBM (Sandeep) commitment in R7.
•  Race Condition Simultaneous requests to update the same info - Config Controller Persona / writers update / APPC VFC SDNC / EMS does update / New yang model will change, SDNR change in network SDNR does go device gets new Yang model puts into the Database. incremental Yang model / PNF package yang model → schema (1 time activity) DB configuration - when you get a config change notification you get all the information you need parameter:newvalue. / who is the MASTER of the data? the mediator / Mirror data - Use Case / the owner controller-persona to update / database update writer

•  ACTION: Find PTL who wants to lead the RTCfgDB Project as independent component.

Email from Dan Timoney 14 Nov 2019 

My understanding from Sandeep was that this work was very much a stretch for Frankfurt.  So, I’m okay with work starting in Frankfurt, as long as its structured so that it’s a separable component (i.e. as long as, if it’s not completed in Frankfurt, the platform is not fundamentally broken). I would NOT support creating a separate repository, since there is a fair amount of overhead involved in maintaining each repository on an ongoing basis – both machine and human resources.  The Linux Foundation itself has been pushing back on the number of repositories the ONAP projects have and there is now a new approval process needed in order to add new ones.  If a new repository is needed, then this team will need to convince me why no existing repository can be used AND will need to provide a resource who is willing to maintain that repository (i.e dealing with security vulnerabilities; policing code coverage ; doing release builds, etc).

Requests for R7 Requirements are up.

Guilin release - functional requirements proposed list

Timeline -  Sign-off for R6 is May 7. Historically M0 kickoff for R7 is May 7th

PROPOSALS FOR R7 GUILIN FOR WHAT WE PLAN TO BE DOING IN R7:

1. R7 Project Proposal (identify PTL, Project proposal, setup repo)
2. =STEP 0= (Design time), (Setup DB) Yang Model development ORAN specification Yang Model in line with 3GPP. SQL structure.
3. =STEP 0= Schema design/setup & API
4. =STEP 1= CMnotify generated by RanSIM extended (final standard format).
5. =STEP 1= VES generation, Nokia Simulate DU → simulate VES CMNotify message.
6. =STEP 1-6= CMNotify (Nokia) Integration Step 2,3,4 with SON work Step 1,5,6
7. =STEP 5/6= Mapping CMnotify contents into DB
8. =STEP 5a= New Development for Independent component to get VES off of DMaaP
9. =STEP 6= API Updates
10. =STEP 6= Interface to RTCDB (writing DB from SDN-R or RCDB-stand-alone-component)

SUMMARY OF THE STEPS FOR RTCDB "HOW IT OPERATES" (Reference):

• STEP 0: Design time, Setup DB schema & API (Onboarding).
• STEP 1: xNF (RAN Simulator) GENERATES a VES CMNotify - Wipro SON (R6 Done)
  
• STEP 1a: Simulator of VES CMNotify/"Standardsdefined/CM" (Nokia) (R7)
• STEP 2: DCAE VES Collector RECEIVES the CMNotify (VES) - Nokia (R7)
  
• STEP 3: DCAE PROCESSES VES Event- Nokia (R7)
  
• STEP 4: DCAE PUBLISHES onto DMaaP - Nokia (R7)
  
• STEP 5: CCSDK (Controller) LISTENS to DMaaP - Sandeep Shah  (R6 Done) → (R7)
  
• STEP 5a: RTCDB (stand-alone component) LISTENS to DMaaP (R7 new)
• STEP 6: RTCfgDB UPDATES DB with info - Sandeep Shah / Techmahindra (R6 Done) → (R7)