In release requirements page:

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

RTCfgDB U/C is YELLOW Stretch goal for CCSDK, SDN-C. Possibly comment added by David McBride or Catherine

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.

MEETING HELD 14 Nov 2019  - Yuriy Malakov Vimal Begwani Benjamin Cheung Joanne Liu Rudel  - discuss way forward, regarding the TSC M1 Score card problem  YELLOW Stretch goal for CCSDK, SDN-C. For R6 The RTCfgDB could part of CC-SDK instead of an independent project. Dan Timoney responded to an email (see following text). Yuriy and Dan could help setup the RTCfgDB as a part of CCSDK. The team continues with the Project Proposal during R6 then present at the Architecture S/C and TSC S/C. ConfigDB already runs as a Virtual Machine. Being part of CCSDK repo. Do we want this to be a PoC? Is the CCSDK scope changing - CCSDK already DBaaS (Database as a Service). what kind of database in CCSDK? MariaDB. Create new docker. (1) potentially what we have today in ConfigDB take it fwd as separate VM or integrate into CCSDK (2) Data model approach. - Q: could this be done as features or as a separate Repo. S/W stack spring framework, connect to underlying DB. created as a new RTCfgDB docker and RESTAPIs. A separate repo is not necessary for this. CCSDK through DGs talk to DB. DT: The way we setup commitments, tied to priorities/Jira epics. Assign priorities if rated as #0 highest, .. rank #3 med if scale back ok; SDN-C & CCSDK reusable, SDN-C create dockers, DGs. creating specific persona. new capabilities in CCSDK. in SDN-C changes to USE these new capabilities. DT: "do we plan to do it? yes" what we mean by a stretch goal is just that it isn't a rank #0, rank #1, ... if you commit to a #3, and you say no to a #0/#1.

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. During the SDNC CCSDK weekly call.

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

• ACTION:   YELLOW Stretch goal for CCSDK, SDN-C. How do we answer the TSC query - The team is saying we are going to do this, for the TSC purposes we can remove the stretch goal.