Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

1- Brief Project Overview (brief as it should be known)

Stores run-time configuration and operational data used by platform components and plug-ins. It provides

RunTime data repository for configuration and operational data.
xNF data is available to any ONAP component via CPS-E-05 (xNF data access).
Component data is available to data owner and with permission to other ONAP components
It is a common services Data layer architecture.
Can sync data with xNFs and sync xNF presence with A&AI.
Temporal data storage and access
Enables: OSS configuration; optimization; LCM operations.
Can be used for: xNF crash restoration; history management; auditing


2- New component capabilities for Honolulu-R8, i.e. the functional enhancements, if applicable

Add remove YANG model

Persist data

CRUD data compliant to YANG model

Forward CUD operations to SDNC

3- New or modified interfaces


4- If they are modified, are they backwards compatible?

Not Applicable

6- Interface naming (point to an example)

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

7- Consumed API from other projects


Interface NamePurpose Reason For UseAPI 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-1This 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-7This 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.


8- Published API

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

Interface Name

Interface Definition

 Interface CapabilitiesProtocol

Honolulu Status

Consumed ModelsAPI Spec (Swagger)
CPS-E-01Provides remote clients with model LCM
Add model (to dataspace)
Remove model (from dataspace)
RESTAvailableAny model defined by YANG languageGerrit link
CPS-E-02Generic data mutation interface

Create an anchor

Delete an anchor

Create data

Delete data

Update data

RESTAvailableNAGerrit link
CPS-E-03Generic read/query interface

Read data

Query data

RESTAvailableNAGerrit link
CPS-E-04Change notificationsSubscribe to DMaaP for changes to dataDMaaPNot available
TBD
CPS-E-05xNF data access

Create data

Delete data

Update data

Read data

Query data

RESTIn scopeNATBD
CPS-E-06Temporal data access

Read data

Query data

RESTIn scopeNATBD
CPS-E-07Administration interface

Low level DB access for administration and troubleshooting

Service interfaces for a GUI

VariousNot availableNATBD

9- Reference to the interfaces.

(Reference to the the swagger.json file(s) whenever possible)

10- What are the system limits?

Not yet available

11- Involved use cases, architectural capabilities or functional requirements.

E2E Network Slicing

SON-PCI (Stretch)

12- Listing of new or impacted models used by the project (for information only).

  • Identify any High Level Information Model Requirements.   See: ONAP R7 Modeling High Level Requirements
    • Models based on information exchanges from Use Cases
    • Models documenting existing implementations
    • Forward looking models that may be implemented in future releases
  • Describe how exposed APIs are mapped to information models

(list all the relevant Jira tickets)


13-Test plan/Testing Strategy

  1. Unit Testing
  2. Dev-to-Dev Testing  and
  3. Integration

Configuration Persistence Service Developer's Landing Page


14- Any other details that are specific to this functional enhancement or UseCase.




  • No labels