Page Status: Update in progress 01/12/2021
Component Status: Pending PTL updates and ArchCom Review
Last Reviewed on:
Certified by:
1. High Level Component Definition and Architectural Relationships
The Configuration Persistence Service (CPS) provides storage for real-time run-time configuration and operational parameters that need to be used by ONAP.
In R8, Honolulu, the CPS is a stand-alone component. Project page is here: Configuration Persistence Service Project
2. API definitions
Configuration Persistence Service provides the following interfaces:
| Interface Name | Interface Definition | Interface Capabilities | Protocol | Honolulu Status | Consumed Models | API Spec (Swagger) |
|---|---|---|---|---|---|---|
| CPS-E-01 | Provides remote clients with model LCM | Add model (to dataspace) Remove model (from dataspace) | REST | Available | Any model defined by YANG language | Gerrit link |
| CPS-E-02 | Generic data mutation interface | Create an anchor Delete an anchor Create data Delete data Update data | REST | Available | NA | Gerrit link |
| CPS-E-03 | Generic read/query interface | Read data Query data | REST | Available | NA | Gerrit link |
| CPS-E-04 | Change notifications | Subscribe to DMaaP for changes to data | DMaaP | Not available | TBD | |
| CPS-E-05 | xNF data access | Create data Delete data Update data Read data Query data | REST | In scope | NA | TBD |
| CPS-E-06 | Temporal data access | Read data Query data | REST | In scope | NA | TBD |
| CPS-E-07 | Administration interface | Low level DB access for administration and troubleshooting | Various | Not available | NA | TBD |
Note: xxxI interface is a Component internal interface. xxxxE interface is a component external interface
The current API documents can be found at:
CPS consumes the following Interfaces:
| Interface Name | Purpose Reason For Use | API Spec (Swagger) | Honolulu status |
|---|---|---|---|
| SDCE-6 | This interface is used to receive the service and resource artifacts (CSAR Package) from SDC. This allows the C&PS DB to process the design-time Yang model artifacts onboarded. STEPS: (1) ONBOARDING - A vendor onboards artifacts describing the parameters supported for their PNFs and VNFs in xNF Package. (2) SDC CATALOG - The onboarded artifacts are stored in the SDC Catalog after onboarding and validated (VNF-SDK). (3) CSAR DISTRIBUTION - The contents of the artifacts are distributed by SDC in a CSAR package onto the DMaaP bus. (4) SETTING UP CPS - S/W to setup the CPS using the content of the CSAR package consumes the SDC CSAR Package. | Not used. xNF model will be fixed (local files) in the Honolulu time-frame | |
| AAIE-1 | This interface is used to automatically add/remove xNF data from CPS in line with xNF presence in AAI | Not used. xNF presence will be fixed (local files) | |
| CONE-7 | This interface is used to read and update data on the xNF | Reading will not be used. Initial state will be fixed (local files) in Honolulu. Writing will be used. |
3. Configuration Persistence Service Component Description:
A more detailed figure and description of the component.
PURPOSE:
REPOSITORY - The types of data that is stored in the Run-Time data storage repository for:
(1) CONFIGURATION PARAMETERS used by xNFs in run time. For example 5G Network run-time instance configuration information. and
(2) OPERATIONAL PARAMETERS used by ONAP and xNFs. Exo-inventory information is information that doesn't belong in A&AI.
- DATA LAKE - It is designed to be a common services data layer which can serve as a data lake.
- SYNCING - The RunTime DB enables the ability to sync data between ONAP & the xNFs. (The source of truth can be define).
- CM FUNCTIONS - Enables OSS configuration, optimization, and LCM operations. (FUTURE)
- CM FUNCTIONS - Enables future CM & Data management functions such as xNF Crash restoration, data restoration, data history management and auditing. (FUTURE)
- CENTRAL/DISTRIBUTED - Because it is a common service, it is part of an ONAP installation, so it could be deployed with either an Edge ONAP installation or a centralized ONAP installation. (FUTURE)
- SCOPE - The Run Time DB could also serve as the data storage to store for example ONAP Policy Rules, CLAMP Control Loop, Operational Views (FUTURE) and also accommodate other resources.
ACCESS (READ/WRITE):
- READ ONLY - Run-Time parameters can be READ by any ONAP platform component and any ONAP plug-in. Examples of ONAP platform components are A&AI, SDC, SDNC etc.
READ/WRITE - Parameters can be READ/WRITE from Controllers, DCAE (future), VES Collector/DMaaP, A&AI, Policy/CLAMP (future) and other components with permission settings.
- DEFAULT - SO (future), DCAE, A&AI, Controllers (CDS, APPC, SDNC) will have default read/write access to RunTime DB
- DEFINABLE - Other components will have default read-only access to RunTime DB but can be given Read/Write access on a per record basis.
SYNCING (INVENTORY):
ELEMENT SYNC - Software keeps the A&AI elements with the elements in the RunTime DB in Sync.
- A&AI - A&AI is still the master of valid entities in the network and provides a dynamic view of the assets (xNFs) available to ONAP
- RUN TIME DB - The RunTime DB is a master of the associate (exo-inventory) data associated with the entities.
- DYNAMIC VIEW - When a xNF appears or is removed from the system, RunTime DB records will be added/removed based on A&AI entries.
INDEXING:
- INDEXING - Data Records will be indexed by xNF (VNF, PNF, ANF).
- RETRIEVAL - How are data records retrieved efficiently. This relates how the records are indexed.
4. Known system limitations
5. Used Models
RunTime DB uses the following models:
- Inventory Model (Run time platform data model)
6. System Deployment Architecture
7. New Capabilities in this Release
This release, RunTime DB adds the following Capabilities:
- In R6 Frankfurt.
8. References
- In R7 this will be PoC which is described here: High Level Design (PoC)