- Tony Finnerty
- Marge Hillis
- Bruno Sakoto
- Zu Qiang (Ericsson)
- N. K. Shankar
- Junfeng Wang
- Melanie Sater
|ARCHITECTURE WORK||WIKI LINK|
|ARCHITECTURE FLOWS||ARCHCOM: InfoFlow - RunTime Config DB Information Flow|
|COMPONENT DESCRIPTION||ARC RunTime DB Component Description - R6 Frankfurt|
|PROJECT PROPOSAL||RunTime Config DB Project Proposal (Oct 25 2019)|
Calendar now open for editing ... but how?
Project as part of CCSDK ( Yuriy Malakov )
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.
Project Proposal work to be done during R6. Project Proposal for R7.
Presentation at Arch S/C and TSC during R6.
Email from Dan Timoney
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).
|Renaming the Project|
Data Persistency Service → "functional"
Data Layer Service
RunTime Configuration DataBase → "technology"
State (of Network) Database