RunTime Config DB Meeting notes Mar 27, 2020
- Benjamin Cheung
Date
Mar 27, 2020
Attendees
@Benjamin Cheung
@Tony Finnerty
@Joanne Liu Rudel
@Former user (Deleted) (Bell Canada)
Ted Johnson
@Zu Qiang
Melanie Sater
@Munir Ahmad (Bell Canada)
--
ARCH WORK
ARCHITECTURE WORK | WIKI LINK |
ARCHITECTURE FLOWS | |
COMPONENT DESCRIPTION | |
PROJECT PROPOSAL |
DISCUSSION
Topic | Discussion |
|---|---|
Calendar Entry | Calendar now open for editing ... but how? |
R6 CCSDK-based Solution | Project as part of CCSDK ( @Yuriy Malakov ) ACTION: @Sandeep Shah Presentation of new architecture with CCSDK. (DONE): 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. Basis for Data Model 3GPP TS28.541/28.540. Planned SQL Schema model driven database work. Once we have schema can SDNR update/provision the schema. Can parsing code be model driven. (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. |
R7 Project Proposal | RunTime Config DB Project Proposal (Oct 25 2019) Project Proposal work to be done during R6. Project Proposal for R7. Presentation at Arch S/C and TSC during R6. ACTION: For Performance (#@#) open items to get ballpark figures for # API requests. ACTION: find out the Lifecycle State "enumerations" ACTION: Schedule presentation time with TSC. / key points in project proposal that must be addressed for them to be considered as a project. Questions that might be asked that need answer. Mandatory fields filled out. @FREEMAN, BRIAN D Mar 20, 2020 Ben sent the TSC asking for slot. Mar 26, 2020 TSC. M4. RC0 bumped by a week. Q1 Who will be contributors. Joanne → Catherine. ACTION: What is our deadline? April 23. Subcommittee meeting (LA USA). planning virtual plannig / presentations. M0 ACTION: Peer Review Process. ONAP Projects ... Ready for PEER REVIEW? What is involved in that? What's the process? submit to the TSC? ACTION: who will be contributors, who wants to be the PTL. |
R7 Separate Component | ACTION: Find PTL who wants to lead the RTCfgDB Project as independent component. Email from @Dan Timoney Nov 14, 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). |
R7 Guilin Content / requirements | 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:
SUMMARY OF THE STEPS FOR RTCDB "HOW IT OPERATES" (Reference):
A&AI FLOWS: STEP 1...6: Initial A&AI setup of DB (the setup of the DB with the initial set of all xNFs a "getall") STEP 1...6: A&AI Update (e.g. a new xNF is added or deleted) |
Renaming the Project | RENAMING THE PROJECT ("Service" vs "Database") Database #1 HISTORICAL PRECEDENCE - The original idea was a configuration database available at Runtime. Use cases to store. Historical been with the project since the beginning. Name Inertia. Operators will use. Historical precedence within AT&T. #2 Contents that it holds - Contents is configuration parameters from the network. Name reflects the initial content of database. Service Since working on project proposal, it has grown, the same argument works against use. #1 QUALIFIERS - A wide variety of qualifiers could be put there and it still won't cover. Would move to something more abstract. Abose and beyond a standard IT database. For example service information, policy information, CLAMP information, exo-inventory (information outside of A&AI), topology information, application information - it is conceivable that many other types of information could before. Config if someone wants to add additional information a place to hold information. e.g. in Bell Canada's case they store more than just configuration, the Operational Data & Current state of network. Collectors that gather metrics in VES consumed put in stateDB. Tied to inventory objects in A&AI self-link from A&AI want to know about interface PNF trying to keep two together, the configuration & the metrics representative what is currently happening in the network. state of I/F being up-down that's more of a state vs a configuration. OpenDaylight Operational data store. Scalability. Collectors & StateDB is yang-driven if collector follows yang-model data store can hold-values. #2 Confederation of Databases - Core/Edge/Far Edge - Historical DB current DB #3 MEANS VS ENDS - Database is a "means" technology not an "end" goal An engine, hubcap is a part of a automobile that provides a service: vehicular motion. A database is a specific technology and implementation. Requirements around for current data & historical (temporal) careful not to talk about the technology. Potentially more than one database. Data Persistency Service → "functional" Data Layer Service Run-Time Configuration DataBase → "technology" State (of Network) Database → what is state of network (storing more than just config) Configuration Operations Database (C.Op.DB) / Swami Golden Configuration Database / Fred RunTime Policy Topology State Configuration Service Exo-Inventory Database |
R7 GuiLin Development | CMNotify specification ACTION: R7 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) VES 7.1 review. Trevor processing comments. Reviewers want= to see reworked document. ACTION: R7 Common Header - David Smith calling meeting talk about how to harmonize / modify common header to deal with notifications to standard bodies. SA5 taken action defining VES events (not good). ONAP should control population of common header. SA5 to change info (CR). Meeting for a high level proposal. Nokia/ ATT/ Orange/ Ericsson. Working towards presentation to ONAP. 3GPP solution to submit CR. Vimal, Marge, Cormac, Damian. NEXT STEP: Follow up call. Deadline: in time for R7. TSC - Ask for TSC presentation Slot. Thursday 10AM EDT. Present the Project Proposal. |
Comment made on Mar 16, 2020 |
@Alessandro D'Alessandro
|
SUPPORTING FILES
Description | File |
|---|---|
|
|
|
|
RECORDING
Recording | File |
|---|---|
Zoom |  |
Audio Only | |
Chat |  |
Action items