...
| 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) |
R6 DISCUSSION
| TOPIC |
|---|
| DISCUSSION | |
|---|---|
R6 CCSDK-based Solution | Project as part of CCSDK ( Yuriy Malakov )
|
R7 DISCUSSION
| Topic | Discussion | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
R6 / R7 ReadtheDocs | Read the Docs
| ||||||||||||||||
R7 TSC / Project Proposal | RunTime Config DB Configuration Persistency Service Project Proposal (Oct 25 2019)
| R7 Separate Component (TSC Project Proposal) |
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:
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)
| ||||||||||||||||
| R7 GuiLin Development | CMNotify specification
|
PROJECT NAME DISCUSSION
| TOPIC | DESCRIPTION |
|---|---|
| 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. SON & Slicing depend on this project (scope) #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. Monitoring interface track as state. #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" / Zu Tony Ben Configuration & Persistency Service / Joanne Tony Ben Operational Persistency Service / Bruno Tony Ben 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)(Operational)(Persistency) Policy Topology State Network Configuration Service Exo-Inventory Database |
CMNotify specification
- (Watch for): R6 VES 7.1.1 Baselined 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)
R7 VES 7.2 review open new updates to the VES listener should include CM VES event. Participate review. - ACTION: R7 VES Common Header update to align with 3GPP SA5 (CR) Nokia/ ATT/ Orange/ Ericsson. Presentation for Monday 2PM UTC on Alla's Req S/C call. "ONAP-ORAN Harmonization". Vimal, Marge, Cormac, Damian. Domain "Standards-Defined" NameSpace "3GPP-CM-xxxx"
SUPPORTING FILES
| Description | File | ||||||
|---|---|---|---|---|---|---|---|
| |||||||
...