Configuration Persistence Service, Honolulu R8, Architecture review
- Tony Finnerty
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
All new, see section 8
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 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. |
8- Published API
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
Unit Testing
Dev-to-Dev Testing and
Integration
CPS Persistence layer (semi-integration) testing
Groovy & Spock Test Code Conventions
Contribution and Development#CodeRequirements
Integration test strategy to be done.