...
Attendees
- Bruno Sakoto
- Joanne Liu Rudel
- Ted Johnson
- Marc-Alexandre Choquette
- Junfeng Wang
- Tony Finnerty
- Zu Qiang (Ericsson)
- Munir Ahmad
- Melanie Sater
- --
ARCH WORK
| 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) |
...
| Topic | Discussion | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Calendar Entry | Calendar now open for editing ... but how? | |||||||||||
R6 CCSDK-based Solution | Project as part of CCSDK ( Yuriy Malakov )
| R6 Frankfurt |
| Jira | ||||||
|---|---|---|---|---|---|---|
|
- .
R7
- 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)
VES 7.1 review. Trevor processing comments. Reviewers want= to see reworked document. - ACTION: 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.
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: PTL
- ACTION: 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. Brian Freeman
- ACTION: What is our deadline?
R7
Separate
Component
- ACTION: Find PTL who wants to lead the RTCfgDB Project as independent component.
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).
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:
- R7 Project Proposal (identify PTL, Project proposal, setup repo)
- =STEP 0= (Design time), (Setup DB) Yang Model development ORAN specification Yang Model in line with 3GPP. SQL structure.
- =STEP 0= Schema design/setup & API
- =STEP 1= CMnotify generated by RanSIM extended (final standard format).
- =STEP 1= VES generation, Nokia Simulate DU → simulate VES CMNotify message.
- =STEP 1-6= CMNotify (Nokia) Integration Step 2,3,4 with SON work Step 1,5,6
- =STEP 5/6= Mapping CMnotify contents into DB
- =STEP 5a= New Development for Independent component to get VES off of DMaaP
- =STEP 6= API Updates
- =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 (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)
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 ("Service" vs "Database")
Database
The original idea was a configuration database available at Runtime. Use cases to store. Historical been with the project since the beginning.
Service
Since working on project proposal, it has grown, the same argument works against use. 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.
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
RunTime Configuration DataBase → "technology"
State (of Network) Database
Configuration Operations Database (C.Op.DB) / Swami
Golden Configuration Database / Fred
Policy Topology Configuration RunTime Service Exo-Inventory Database
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
- (CLOSED) Vendor/SP may have an independent database (outside of ONAP) that they may wish to "sync" up with the RTCDB
- . Data in that independent DB maybe overlapping
- information
- . Store directly data inside of one data-lake already used by the SP.
- SP already has an existing Data lake → use that instead of RTCDB. UPDATE: The proj. proposal does (1) have a section on synchronization (2) facade I/F
Alessandro Gerardo D'Alessandro
SUPPORTING FILES
| Description | File | ||||||
|---|---|---|---|---|---|---|---|
Presentation made at Requirements S/C on |
| ||||||
RECORDING
| Recording | File | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Zoom |
| ||||||||||||||||||
Audio Only |
| ||||||||||||||||||
| Chat |
|
Action items
...