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.

Since R8, Honolulu, the CPS is a stand-alone component. Project page describing eventual scope and ambition is here: Configuration Persistence Service ProjectThis page reflects the CPS for Istanbul.

2. API definitions

Interfaces provided by Configuration Persistence Service

Excerpt

06CPS-E- 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 Read the docs CPS-E-02 Generic data mutation interface Create an anchor Delete an anchor Create data Delete data Update data REST Available NA Read the docs CPS-E-03 Generic read/query interface Read data Query data REST Available NA Read the docs 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 CPS-391Spike: Define and Agree NCMP REST Interface CPS-E- Temporal data access Read data Query data REST In scope NA CPS-251 Define REST Query interface for Temporal service 07 Administration interface Low level DB access for administration and troubleshooting Service interfaces for a GUI Various Not available NA TBD

Note:   xxxI interface is a Component internal interface.  xxxxE interface is a component external interfaceCPS consumes the following Interfaces:

Interfaces consumed by CPS

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.
    

  • (3) COMPONENT DATA used by ONAP components to persist data does not belong in A&AI and is not part of the xNF models.
• DATA LAKE - It is designed to be a common services data layer which can serve as a data lake for xNF data.
  
• SYNCING - The RunTime DB enables the ability to sync data between ONAP & the xNFs. (The source of truth can be defined). (FUTURE)
  
• 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):

• xNF Data - Run-Time parameters can be READ/WRITE by any ONAP platform component and any ONAP plug-in via the xNF data access interface. Examples of ONAP platform components are A&AI, SDC, SDNC etc.
  

• Non-xNF Data - Parameters can be READ/WRITE by owner.
  

• ACCESS CONTROL - The data owner may grant permission to other components to READ and/or WRITE non-xNF data.  (FUTURE)

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
• CPS (xNF Proxy) - The CPS is the owner (within ONAP) of the associate (exo-inventory) data associated with the xNFs.
• DYNAMIC VIEW - When a xNF appears or is removed from the system, CPS records will be added/removed based on A&AI entries.

3.1 Concepts

A dataspace is a logical separation of data within the CPS. Dataspaces are created by data owners.

An anchor is a logical separation of data within a dataspace. An anchor is associated with a set of YANG modules (model). Models are used to validate data. Anchors are created by data owners.

Anchor and dataspace concepts are described in a presentation here.

An owner is an ONAP component that is responsible for data in the CPS. Responsibility includes deciding how data is exposed to other ONAP components. Options being:

1. Data is exposed via µService APIs – no direct access to data via CPS interfaces
2. Data is exposed via CPS interfaces – requires registration/discovery and access control to be implemented (FUTURE)

Data ownership and access control are the mechanisms provided by CPS for ONAP to avoid uncontrolled coupling in the data layer.

4. Known system limitations

In Istanbul, the inventory, xNF models, and initial data may be provided by a temporary REST interface provided by the ONAP DMI plugin.

5. Used Models

RunTime DB uses the following models:

• Inventory Model (Run time platform data model)
• ran-network@2020-08-06.yang – static YANG model for Honolulu

6. System Deployment Architecture

CPS project (yellow area in picture) will be deployed as several micro services:

1. Blue ≡ CPS & NCMP µS – providing most interfaces described above
2. Green ≡ ONAP DMI plug-in µS – providing integration with SDNC, AAI & SDC
3. Orange ≡ Temporal stack µS – provides access to a temporal view of data
4. Purple ≡ DBMS µS – One or more DBMS instances, optionally dedicated or shared for temporal and current CM data
5. Brown ≡ TBDMT µS – Data model transformation and presentation (API Mapping)

See also CPS-NCMP ↔ DMI-Plugin Interface Details Jakarta-R10

7. New Capabilities in this Release

This release, CPS adds the following Capabilities:

• Extending xNF data write forwarding (delete, update, patch)
• Extend Sync to include data sync and maintaining sync state
• AAI integration
• read access to cached data (datastore ncmp-datastores:operational)

8. References

1. Ongoing development: Configuration Persistence Service Developer's Landing Page
2. CPS backlog: https://jira.onap.org/secure/RapidBoard.jspa?rapidView=228&view=planning.nodetail&quickFilter=713&issueLimit=100
3. Deployment view: CPS-78: Deployment View