DESCRIPTION: Configuration Persistence Service (CPS) is a data lake repository for configuration and operational parameters. Configuration Persistence Service is a common service component that ONAP components can access write and read information to. The term "config" is used in the name for legacy purposes, but the use case is not limited to just configuration parameters and it is intended to be a repository for Operational parameters, and eventually policy information.

WHEN EXECUTED: This information flow is used during Run Time, when configuration or operational data is written to the Configuration Persistence Service.

• Flow 1 (Write) - VES Configuration information coming from xNF via e.g. CM Notify

• Flow 2 (Write) - New xNF is added or deleted from ONAP; A&AI notification xNF update.

• Flow 3 (Write) - Micro-Service or ONAP component writing & updating operational information

• Flow 4 (Read) - Data is read from Configuration Persistence Service

PURPOSE: Configuration Persistence Service serves as a data lake as a common service and data layer for ONAP components and micro-services.

INFORMATION PASSED: Configuration information (from CM Notify) or operational information (derived during ONAP operations).

ACTORS:

• Configuration Persistence Service

• Operations Specialist (ONAP user)

• Controller/ONAP Component, A&AI, VES collector/DMaaP

For more information and details you can visit the RunTime DB Use Case Wiki at: CONFIGURATION PERSISTENCE SERVICE R6

The: ARC RunTime DB Component Description - R6 Frankfurt

wiki describes a more detailed figure and description of the component.

PURPOSE OF RUNTIME CONFIG DB:

• 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) POLICY INFORMATION - FUTURE - Policy, CLAMP Control Loops, Operational Views

• DATA LAKE - It is designed to be a common services data layer which can serve as a data lake.
  
  

• SYNCING - The CPS 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 TO RUNTIME DB (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 (indirectly), 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 NEW xNF ADDED or DELETED (A&AI):

• ELEMENT SYNC - Software keeps the A&AI elements with the elements in CPS in Sync. When the network first being established, a GetAllPNFs function from A&AI can be used on startup.

• 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 DB - CPS 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.

• LOGIC - When a xNF appears is removed there is logic to determine how and when something is to be updated. There is some intelligence to know what elements of update.

INDEXING:

• INDEXING - Data Records will be indexed by xNF (VNF, PNF, ANF). It would be an objective to have a similar indexing mechanism as A&AI. May also need an index to be a logical object ID.
  
  

• RETRIEVAL - How are data records retrieved efficiently. This relates how the records are indexed.

Open

The above diagram shows the usage of CPS

It shows the four basic flows captured in the diagram.

• Writing information from a VES CM Notify event

• A&AI xNF addition/deletion

• Operational information written

• Information being read from the RunTimeDB