/
ARC Configuration Persistence Service (CPS) Component Description - Honolulu-R8

ARC Configuration Persistence Service (CPS) Component Description - Honolulu-R8

Owned by Chaker Al-Hakim
Last updated: Jan 20, 2021 by Tony Finnerty
5 min read
Page Status: Update in progress Jan 12 2021

Component Status: Pending PTL updates and ArchCom Review

Last Reviewed on:

Certified by: @Toine Siebelink

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 describing eventual scope and ambition is here: Configuration Persistence Service Project

This page reflects the ambitions for Honolulu.



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

Service interfaces for a GUI

Various

Not available

NA

TBD



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

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.

    • (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 Honolulu, the inventory, xNF models, and initial data will be statically defined in files. This will be coordinated with other components participating in the E2E network slicing use case. Changes to these definitions will require a redeployment of CPS.

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 will be deployed as two micro services:

  1. PostgreSQL µS – requiring a physical volume (Current version 13.1)

  2. CPS µS – providing all interfaces described above

7. New Capabilities in this Release

This release, CPS adds the following Capabilities:

  • Model LCM

  • Generic data CRUD

  • xNF data CRUD

  • xNF data write forwarding

8. References

  1. The R7 PoC is described here: High Level Design (PoC)

  2. Ongoing development: Configuration Persistence Service Developer's Landing Page

  3. CPS backlog: https://jira.onap.org/secure/RapidBoard.jspa?rapidView=228&view=planning.nodetail&quickFilter=713&issueLimit=100

  4. Decision log: Issues decisions and assumptions

  5. Deployment view: CPS-78: Deployment View











Related content