Project as part of CCSDK ( Yuriy Malakov  )

• ACTION: Sandeep Shah Presentation of new architecture with CCSDK.
• (Done): 10 Jan 2020 Architecture CCSDK component: ARC Controller Component Description – Frankfurt added in Section 6 System deployment architecture. Separate container. Added to Diagram. Updated Section 7 New Release Capabilities & Linked to U/C page.
• ACTION: Development demo & progress in use on OOF/PCI/SON Use Case. Validation tool & generation of schemas/tables of input conditions of yang model. Planned SQL Schema model driven database work. Once we have schema can SDNR update/provision the schema. Can parsing code be model driven.

In release requirements page: M4 March 5, 2020

Frankfurt Release Requirements (TSC has already approved Green status for U/C).

CCSDK, SDN-C - Dan Timoney MVP (min viab. product) discussed on SDN-C call. Req not totally clear, schema model. Take what is in ConfigDB; finalize the Data Model approach.

MEETINGS HELD 14 Nov 2019 RTCfgDB in CCSDK

08 Nov 2019 CCSDK, 06 Nov 2019 SDN-C call - ConfigDB is already part of DBaaS. Req not finalized. Data model already in use. and API creation.

• ACTION: 10 Jan 2020 for Sandeep Shah / API Documentation - freeze, the schema for the RunTime DB needs to be defined. Sandeep Shah has indicated it is ready. Need to see code to that effect. Should be documented somewhere. Joanne & Ben will meet Sandeep
  
• ACTION:  CCSDK Jira ticket for RTCfgDB into CCSDK - CCSDK-1963 - Getting issue details... STATUS
  
• ACTION: Convert yang model in SDN-R to be used into CCSDK. RTCfgDB will be used for OOF/SON/PCI first. Yang model as used by OOF/SON/PCI to convert. Yang model from SDN-R > CCSDK. SDN-C gets yang model from SDC. Yang to SQL. Need to have 1 Yang model. Martin Skorupski
  Corry over to next meeting
• ACTION: Activity #1 Wipro team is looking to create a CMNotify mock-up for testing & demo purposes. Sandeep Shah  ; place on DMaaP and have them parse. would like to see VES mock-up version 7.2. Not changing the VES Collector. What should be generated from RAN-Simulator (input); what kind of output of DCAE to DMaaP message will be received (output) Activity #2 Nokia offered to contribute the code to support the additional domain & routing & processing of CMNotify VES events in DMaaP (R7).

• STEP 1: xNF (RAN Simulator) GENERATES a VES CMNotify - Wipro SON (R6)
  
• STEP 2: DCAE VES Collector RECEIVES the CMNotify - Nokia (R7)
  
• STEP 3: DCAE PROCESSES Event- Nokia (R7)
  
• STEP 4: DCAE PUBLISHES onto DMaaP - Nokia (R7)
  
• STEP 5: CCSDK (Controller) LISTENS to DMaaP - Sandeep Shah  (R6)
  
• STEP 6: RTCfgDB UPDATES with info - Sandeep Shah / Techmahindra Devendra Chauhan (R6) 
  

• ACTION: CMNotify VES Review https://gerrit.onap.org/r/c/vnfrqts/requirements/+/100876  (VES Event Reg review) and https://gerrit.onap.org/r/c/vnfrqts/requirements/+/100867 (VES Event Listener review)
  review to 07 Feb 2020 (off-line review); David Smith calling meeting for 07 Feb 2020 
  

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