ARC Configuration Persistence Service (CPS) Component Description - Guilin (R7) Release

Owned by Chaker Al-Hakim
Last updated: Nov 27, 2020 by Benjamin Cheung
3 min read
Page Status: Copied from R6 - Mar, 22, 2020
Component Status: Pending PTL Updates and ArchCom Review

Last Reviewed:

Certified by: @Benjamin Cheung  @Tony Finnerty



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 R7 this will be PoC which is described here: High Level Design (PoC)

In R8, Honolulu, the CPS will be a stand-alone component.



2. API definitions



Configuration & Pesistency provides the following interfaces:



Interface Name

Interface Definition

 Interface Capabilities

Protocol

Status

Consumed Models

API Spec (Swagger)

Interface Name

Interface Definition

 Interface Capabilities

Protocol

Status

Consumed Models

API Spec (Swagger)

CPSE-1

Configuration & Persistency Service DB Model Interface. 

Model life cycle (add and remove models)

REST







CPSE-2

Access

Data access interface (CRUD)

REST







CPSE-3

Update

Notification of data change (configured by model)

DMaaP







CPSE-4

Configuration & Persistency Service DB Graphical User Interfaces  (GUI)

Provides the capability to view and edit the data currently in the C&PS DB.

This GUI is meant to allow an operations user of ONAP to view the data stored in the RunTime DB during Run Time operation.









Note:   xxxI interface is a Component internal interface.  xxxxE interface is a component external interface

The current API documents can be found at:

RTDB consumes the following Interfaces:

Interface Name

Purpose Reason For Use

API Spec (Swagger)

Interface Name

Purpose Reason For Use

API Spec (Swagger)

SDCE-7

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 RUNTIME DB - S/W to setup the RunTime DB using the content of the CSAR package consumes the SDC CSAR Package.





3. Configuration & Persistency 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

  1.