CPS Documentation
CPS
CPS Overview
The Configuration Persistence Service (CPS) is a platform component that is designed to serve as a data repository for runtime data that needs persistence.
Types of data that is stored:
Configuration Parameters
These are configuration parameters that are used by xNFs during installation & commissioning. Configuration parameters are typically used before the xNF has been brought up or is operational. For example, a 5G Network configuration parameter for a PNFs that sets the mechanical tilt which is a configuration setting upon installation.
Operational Parameters
This operational information could be either an actual state or configuration of a network service or device. These are parameters that are derived, discovered, computed that are used by xNFs during run time AFTER the xNF becomes operational i.e. AFTER it has “booted up”, been installed or configured. For example, in 5G Network, 5G PNFs may need to adjust a tower electrical antenna tilt. These operational parameters are Exo-inventory information, meaning it is information that doesn’t belong in A&AI. In principle, some parameters might be both configuration and operational parameters depending on how they are used.
CPS Components
CPS-Core
This is the component of CPS which encompasses the generic storage of Yang module data.
NCMP
The Network Configuration Management Proxy (NCMP) provides access to network configuration data and is a part of CPS-Core. NCMP accesses all network Data-Model-Inventory (DMI) information via NCMP-DMI-Plugins. The ONAP0-DMI-Plugin described in the next section is one such plugin.
Note: This documentation will often refer to “CPS-NCMP” which is the component (container image) that contains both CPS-Core and NCMP since NCMP is not a stand-alone component even though CPS-Core could be deployed without the NCMP extension.
NCMP-DMI-Plugin
The Data-Model-Inventory (DMI) Plugin is a rest interface used to synchronize CM-Handles data between CPS and DMI through the DMI-Plugin. This is built previously from the CPS-NF-Proxy component.
CPS-Temporal
This service is responsible to provide a time oriented perspective for operational network data. It provides features to store and retrieve sequences of configurations or states along with the associated times when they occurred or have been observed.
CPS Project
Contact Information: onap-discuss@lists.onap.org
CPS Architecture
High Level Component Definition and Architectural Relationships
The Configuration Persistence Service (CPS) provides storage for run-time configuration and operational parameters that need to be used by ONAP.
In this release CPS is no longer a stand alone component and is released along with Cps-Temporal and the NCMP-DMI-Plugin.
Project page describing eventual scope and ambition is here: Configuration Persistence Service Project
This page reflects the state for Istanbul-R9 release.
Note: SDC and AAI interfaces have not yet been implemented.
API definitions
Configuration Persistence Service provides the following interfaces.
Interface name |
Interface definition |
Interface capabilities |
Protocol |
|---|---|---|---|
CPS-E-01 |
Administrative Data Management |
|
REST |
CPS-E-02 |
Generic Data Access |
|
REST |
CPS-E-03 |
Generic Data Search |
|
REST |
CPS-E-04 |
Change Notification |
|
Kafka |
CPS-E-05 |
xNF Data Access |
|
REST |
CPS-E-06 |
Temporal Data Access |
|
REST |
CPS-E-07 |
Admin |
|
Various |
The CPS Basic Concepts are described in CPS Modeling.
CPS Admin Guide
Logging Configuration
Note
Default logging level of “logging.level.org.onap.cps” is set to “INFO”.
logging:
level:
org:
springframework: INFO
onap:
cps: INFO
CPS Log pattern
<pattern>
{
"logTimeStamp" : "%timestamp", // 2022-01-28 18:39:17.768
"logLevel": "%level", // DEBUG
"principalId": "%userId", // cpsuser
"serviceName": "${springAppName}", // cps-application
"message":"%message", // Execution time ...
"processId": "${PID}", //11128
"threadName": "%thread", //tp1901272535-29
"class": "%logger{40}", .// o.onap.cps.aop.CpsLoggingAspectService
}
</pattern>
Change logging level
Curl command 1. Check current log level of “logging.level.org.onap.cps” if it is set to it’s default value (INFO)
curl --location --request GET 'http://{cps-service-name:cps-management-port}/manage/loggers/org.onap.cps' \
--header 'Content-Type: application/json; charset=utf-8'
Response body : HTTP Status 200
{
"configuredLevel": "INFO",
"effectiveLevel": "INFO"
}
Curl command 2. Change logging level of “logging.level.org.onap.cps” to “DEBUG”
Note
Below-mentioned endpoint will change the log level at runtime. After executing the curl command “effectiveLevel” will set and applied immediately without restarting CPS service.
curl --location --request POST 'http://{cps-service-name:cps-management-port}/manage/loggers/org.onap.cps' \
--header 'Content-Type: application/json; charset=utf-8' \
--data-raw '{
"configuredLevel": "DEBUG"
}'
Response body : HTTP Status 204
Curl command 3. Verify if log level of “logging.level.org.onap.cps” is changed from ‘INFO’ to ‘DEBUG’
curl --location --request GET 'http://{cps-service-name:cps-management-port}/manage/loggers/org.onap.cps' \
--header 'Content-Type: application/json; charset=utf-8'
Response body : HTTP Status 200
{
"configuredLevel": "DEBUG",
"effectiveLevel": "DEBUG"
}
Location of log files
By default, Spring Boot will only log to the console and will not write log files.
Measure Execution Time of CPS Service
Note
Make sure effective log level of “logging.level.org.onap.cps” is ‘DEBUG’. This can be verified by executing curl command 3.
Execute CPS service that you want to calculate total elapsed time and log as shown below
2022-01-28 18:39:17.679 DEBUG [cps-application,e17da1571e518c59,e17da1571e518c59] 11128 --- [tp1901272535-29] o.onap.cps.aop.CpsLoggingAspectService : Execution time of : DataspaceRepository.getByName() with argument[s] = [test42] having result = org.onap.cps.spi.entities.DataspaceEntity@68ded236 :: 205 ms
2022-01-28 18:39:17.726 DEBUG [cps-application,e17da1571e518c59,e17da1571e518c59] 11128 --- [tp1901272535-29] o.onap.cps.aop.CpsLoggingAspectService : Execution time of : AnchorRepository.getByDataspaceAndName() with argument[s] = [org.onap.cps.spi.entities.DataspaceEntity@68ded236, bookstore] having result = org.onap.cps.spi.entities.AnchorEntity@71c47fb1 :: 46 ms
2022-01-28 18:39:17.768 DEBUG [cps-application,e17da1571e518c59,e17da1571e518c59] 11128 --- [tp1901272535-29] o.onap.cps.aop.CpsLoggingAspectService : Execution time of : CpsAdminPersistenceServiceImpl.getAnchor() with argument[s] = [test42, bookstore] having result = Anchor(name=bookstore, dataspaceName=test42, schemaSetName=bookstore) :: 299 ms
2022-01-28 18:39:17.768 DEBUG [cps-application,e17da1571e518c59,e17da1571e518c59] 11128 --- [tp1901272535-29] o.onap.cps.aop.CpsLoggingAspectService : Execution time of : CpsAdminServiceImpl.getAnchor() with argument[s] = [test42, bookstore] having result = Anchor(name=bookstore, dataspaceName=test42, schemaSetName=bookstore) :: 305 ms
2022-01-28 18:39:17.843 DEBUG [cps-application,e17da1571e518c59,e17da1571e518c59] 11128 --- [tp1901272535-29] o.onap.cps.aop.CpsLoggingAspectService : Execution time of : AdminRestController.getAnchor() with argument[s] = [test42, bookstore] having result = <200 OK OK,class AnchorDetails {
name: bookstore
dataspaceName: test42
schemaSetName: bookstore
},[]> :: 419 ms
Warning
Revert logging level of “logging.level.org.onap.cps” to ‘INFO’ again to prevent unnecessary logging and impacts on performance.
Logging & Diagnostics
General Guidelines
CPS-Core logs are sent to STDOUT in order to leverage the Kubernetes logging architecture.
These logs are available using the following command:
kubectl logs <cps-core-pod>
The default configuration for CPS logs is the INFO level.
This architecture also makes all logs ready to be sent to an Elastic-search Log-stash and Kibana (ELK) stack or similar.
Enabling tracing for all executed sql statements is done by changing hibernate loggers log level
Logger configuration is provided as a chart resource :
cps-component-service-name
logback.xml location
cps-core
cps-temporal
ncmp-dmi-plugin
Not yet applicable to DMI-Plugin
Monitoring
Once CPS-Core is deployed, information related to the running instance of the application is available
http://<cps-component-service-name>:8081/manage/info/
Health
Cps-Core health status and state can be checked using the following endpoint. This also includes both the liveliness state and readiness state.
http://<cps-component-service-name>:8081/manage/health/
Metrics
Prometheus Metrics can be checked at the following endpoint
http://<cps-component-service-name>:8081/manage/prometheus
Naming Validation
As part of the Kohn 3.1.0 release, CPS has added validation to the names of the following components:
Dataspace names
Schema Set names
Anchor names
Cm-Handle identifiers
The following characters along with spaces are no longer valid for naming of these components.
!"#$%&'()*+,./\:;<=>?@[]^`{|}~
CPS Design
Offered APIs
CPS supports the public APIs listed in the following sections.
CPS-Core
CPS-Core functionality.
CPS-NCMP
XNF data access and module information.
CPS-NCMP-Inventory
DMI-Plugin Inventory.
View Offered APIs
The standard for API definition in the RESTful API world is the OpenAPI Specification (OAS). The OAS 3, which is based on the original “Swagger Specification”, is being widely used in API developments.
Specification can be accessed using following URI:
http://<hostname>:<port>/v3/api-docs?group=cps-docket
Additionally, the Swagger User Interface can be found at the following URI. The component may be changed between CPS-Core, CPS-NCMP and CPS-NCMP-Inventory using the drop down table in the top right:
http://<hostname>:<port>/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config#/
Consumed APIs
CPS Core uses API’s from the following ONAP components
DMI-Plugin: REST based interface which is used to provide integration and allow the DMI registry API’s have access to the corresponding NCMP API’s within CPS Core. More information on the DMI-Plugins offered APIs can be found on the DMI-Plugin’s Design Page.
CPS Path
Several CPS APIs use the cps-path (or cpsPath in Java API) parameter. The CPS Path is described in detail in CPS Path.
NCMP CM Handle Querying
The CM Handle searches endpoints can be used to query for CM Handles or CM Handle IDs. This endpoint is described in detail in CM Handle Query Endpoints.
CPS Modeling
CPS-Core Modeling
Data Model
Basic Concepts
Administrative entities
Dataspace is a primary logical separation of data.
Any application can define its own dataspace to store the model(s) and data it owns. Dataspace is uniquely identified by it’s name.
Schema Set describes a data model(s).
Schema Set holds reference(s) to single or multiple YANG modules. Schema Set belongs to dataspace and uniquely identified by its name (within its own dataspace). Same YANG resources (source files) can be referenced by multiple schema sets from different dataspaces.
Anchor identifies the unique data set (data record) within a dataspace.
Anchor always references a schema set within same dataspace which describes a data model of associated data. Multiple anchors may reference same schema set. Anchor is uniquely identified by its name (within own dataspace).
Data
Data Node represents a data fragment.
Each data node can have zero or more descendants and together they form a data instance tree. The data node tree belongs to an anchor.
Data node is representing a data fragment described in a YANG model as a container and/or a list. The data described as a leaf and/or a leaf-list are stored within a parent data node.
The data node position within a tree is uniquely identified by the node’s unique xpath which can be used for partial data query.
Querying
CPS Path is used to query data nodes.
CPS Path
Several CPS APIs use the CPS path (or cpsPath in Java API) parameter. The CPS path parameter is used for querying xpaths. CPS path is inspired by the XML Path Language (XPath) 3.1.
This section describes the functionality currently supported by CPS Path.
module stores {
yang-version 1.1;
namespace "org:onap:ccsdk:sample";
prefix book-store;
revision "2020-09-15" {
description
"Sample Model";
}
container shops {
container bookstore {
leaf bookstore-name {
type string;
}
leaf name {
type string;
}
list categories {
key "code";
leaf code {
type uint16;
}
leaf name {
type string;
}
leaf numberOfBooks {
type uint16;
}
container books {
list book {
key title;
leaf title {
type string;
}
leaf price {
type uint16;
}
leaf-list label {
type string;
}
leaf-list edition {
type string;
}
}
}
}
}
}
}
Note. ‘categories’ is a Yang List and ‘code’ is its key leaf. All other data nodes are Yang Containers. ‘label’ and ‘edition’ are both leaf-lists.
Note. CPS accepts only json data. The xml data presented here is for illustration purposes only.
The json and xml below describes some basic data to be used to illustrate the CPS Path functionality.
{
"shops": {
"bookstore": {
"bookstore-name": "Chapters",
"name": "Chapters",
"categories": [
{
"code": 1,
"name": "SciFi",
"numberOfBooks": 2,
"books": {
"book": [
{
"title": "2001: A Space Odyssey",
"price": 5,
"label": ["sale", "classic"],
"edition": ["1968", "2018"]
},
{
"title": "Dune",
"price": 5,
"label": ["classic"],
"edition": ["1965"]
}
]
}
},
{
"code": 2,
"name": "Kids",
"numberOfBooks": 1,
"books": {
"book": [
{
"title": "Matilda"
}
]
}
}
]
}
}
}
<shops>
<bookstore name="Chapters">
<bookstore-name>Chapters</bookstore-name>
<categories code=1 name="SciFi" numberOfBooks="2">
<books>
<book title="2001: A Space Odyssey" price="5">
<label>sale</label>
<label>classic</label>
<edition>1968</edition>
<edition>2018</edition>
</book>
<book title="Dune" price="5">
<label>classic</label>
<edition>1965</edition>
</book>
</books>
</categories>
<categories code=2 name="Kids" numberOfBooks="1">
<books>
<book title="Matilda" />
</books>
</categories>
</bookstore>
</shops>
String values must be wrapped in quotation marks
"(U+0022) or apostrophes'(U+0027).String comparisons are case sensitive.
List key-fields containing
\or@[will not be processed correctly when being referenced with such key values in absolute or descendant paths. This means such entries will be omitted from any query result. See CPS-500 Special Character Limitations of cpsPath Queries
( <absolute-path> | <descendant-path> ) [ <leaf-conditions> ] [ <text()-condition> ] [ <ancestor-axis> ]
Each CPS path expression need to start with an ‘absolute’ or ‘descendant’ xpath.
Syntax: '/' <container-name> ( '[' <list-key> ']' )? ( '/' <containerName> ( '[' <list-key> ']' )? )*
container name: Any yang container or list.
list-key: One or more key-value pairs, each preceded by the@symbol, combined using theandkeyword.The above van repeated any number of times.
- Examples
/shops/bookstore/shops/bookstore/categories[@code='1']/books/shops/bookstore/categories[@code='1']/books/book[@title='2001: A Space Odyssey']
- Limitations
Absolute paths must start with the top element (data node) as per the model tree.
Each list reference must include a valid instance reference to the key for that list. Except when it is the last element.
Syntax: '//' <container-name> ( '[' <list-key> ']' )? ( '/' <containerName> ( '[' <list-key> ']' )? )*
The syntax of a descendant path is identical to a absolute path except that it is preceded by a double slash
//.
- Examples
//bookstore//categories[@code='1']/books//bookstore/categories
- Limitations
Each list reference must include a valid instance reference to the key for that list. Except when it is the last element.
- Syntax:
<xpath> '[' @<leaf-name1> '=' <leaf-value1> ( ' and ' @<leaf-name> '=' <leaf-value> )* ']' xpath: Absolute or descendant or xpath to the (list) node which elements will be queried.leaf-name: The name of the leaf which value needs to be compared.leaf-value: The required value of the leaf.
- Examples
/shops/bookstore/categories[@numberOfBooks=1]//categories[@name="Kids"]//categories[@name='Kids']//categories[@code='1']/books/book[@title='Dune' and @price=5]//categories[@code=1]
- Limitations
Only the last list or container can be queried leaf values. Any ancestor list will have to be referenced by its key name-value pair(s).
Multiple attributes can only be combined using
and.orand bracketing is not supported.Only leaves can be used, leaf-list are not supported.
Only string and integer values are supported, boolean and float values are not supported.
The key should be supplied with correct data type for it to be queried from DB. In the last example above the attribute code is of type Integer so the cps query will not work if the value is passed as string. eg:
//categories[@code="1"]or//categories[@code='1']will not work because the key attribute code is treated a string.Having ‘[’ token in any index in any list will have a negative impact on this function.
- Notes
For performance reasons it does not make sense to query using key leaf as attribute. If the key value is known it is better to execute a get request with the complete xpath.
The text()-condition can be added to any CPS path query.
- Syntax:
<cps-path> ( '/' <leaf-name> '[text()=' <string-value> ']' )? cps-path: Any CPS path query.leaf-name: The name of the leaf or leaf-list which value needs to be compared.string-value: The required value of the leaf or leaf-list element as a string wrapped in quotation marks (U+0022) or apostrophes (U+0027). This wil still match integer values.
- Examples
//book/label[text()="classic"]//book/edition[text()="1965"]
- Limitations
Only the last list or container can be queried for leaf values with a text() condition. Any ancestor list will have to be referenced by its key name-value pair(s).
Only one leaf or leaf-list can be tested.
Only string and integer values are supported, boolean and float values are not supported.
Since CPS cannot return individual leaves it will always return the container with all its leaves. Ancestor-axis can be used to specify a parent higher up the tree.
When querying a leaf value (instead of leaf-list) it is better, more performant to use a text value condition use @<leaf-name> as described above.
Having ‘[’ token in any index in any list will have a negative impact on this function.
The ancestor axis can be added to any CPS path query but has to be the last part.
- Syntax:
<cps-path> ( '/ancestor::' <ancestor-path> )? cps-path: Any CPS path query.ancestor-path: Partial path to ancestors of the target node. This can contain one or more ancestor nodes separated by a/.
- Examples
//book/ancestor::categories//categories[@code='2']/books/ancestor::bookstore//book/ancestor::categories[@code='1']/books//book/label[text()="classic"]/ancestor::shops
- Limitations
Ancestor list elements can only be addressed using the list key leaf.
List elements with compound keys are not supported.
NCMP Modeling
Data Model
NCMP stores DMI-Plugin and CM Handle relations using a data model described as per this Yang module.
Note: Although additional-properties are present in the model of the dmi-registry, these are considered private metadata and as such are not queryable.
Basic Concepts
CM-Handle represents an instance a modeled Network Function(node) in ONAP.
These are stored as Anchors within CPS-Core.
CM-Handle States are used to represent the potential states in which a CM-Handle can transition between.
The 5 possible CM-Handle states are: ADVISED, READY, LOCKED, DELETING, DELETED
ADVISED indicates that a CM-Handle has been registered successfully, and is waiting for the module synchronization process to sync the CM-Handle.
READY indicates that the CM-Handle has been synced successfully.
LOCKED indicates that the CM-Handle has not synced successfully. A retry mechanism within CPS will set the state back to ADVISED after a set time.
DELETING indicates that the CM-Handle is currently being deleted.
DELETED indicates that the CM-Handle has been deleted successfully.
Data-sync state is the state of the data synchronization process of the CM-Handle
There are 3 possibles states: NONE_REQUESTED, UNSYNCHRONIZED, SYNCHRONIZED
NONE_REQUESTED indicates that the data sync is not requested by the user
UNSYNCHRONIZED indicates the cm-handle is waiting for the data sync watchdog operation to carry out the sync process
SYNCHRONIZED indicates the watchdog process has finished the data synchronization successfully
Datastores represent different views of the cm data.
Datastores are defined for NCMP to access the CPS running or operational datastores. Currently supported datastores are:
Datastore
Configurations
Data access type
Passthrough-operational
config-true, config-false
read-only
Passthrough-running
config-true
read-write
Querying CM Handles
CM Handle Searches Endpoints are used to query CM Handles.
CM Handle Query Endpoints
For querying CM Handles we have two Post endpoints:
ncmp/v1/ch/searches Returns all CM Handles which match the query properties provided. Gives a JSON payload of the details of all matching CM Handles.
ncmp/v1/ch/id-searches Returns all CM Handles IDs which match the query properties provided. Gives a JSON payload of the ids of all matching CM Handles.
/searches returns whole CM Handle object (data) whereas /id-searches returns only CM Handle IDs. Otherwise these endpoints are intended to be functionally identical so both can be queried with the same request body. If no matching CM Handles are found an empty array is returned.
Currently this endpoint allows three criteria to be query on:
hasAllModules returns CM Handles which have the module names provided.
hasAllProperties returns CM Handles which have the properties (key and value) provided.
cmHandleWithCpsPath returns CM Handles which match the CPS Path provided.
Not all request body combinations have been validated and as such request bodies which do not conform to the structure as documented here can produce results in which all CM Handles are returned.
Note
By convention REST JSON return bodies use ‘camelCasing’. By convention field names in yang modelled data use ‘kebab-casing’. Therefore some inconsistencies can be seen in the JSON use in CPS REST interfaces. For CM Handle related endpoints we return data in ‘camelCasing’. But for cmHandleWithCpsPath, the query is accessing yang modelled field names and as such needs to use ‘kebab-casing’. Therefore the dmi-registry field names should be referenced when using the cmHandleWithCpsPath condition: CPS Modeling
Request Body example using all available query criteria. This query would return all CM Handles which have the specified modules my-module-(1-3), have the specified properties of Color yellow, Shape circle, Size small and are in a sync state of ADVISED:
{
"cmHandleQueryParameters": [
{
"conditionName": "hasAllModules",
"conditionParameters": [
{
"moduleName": "my-module-1"
},
{
"moduleName": "my-module-2"
},
{
"moduleName": "my-module-3"
}
]
},
{
"conditionName": "hasAllProperties",
"conditionParameters": [
{
"Color": "yellow"
},
{
"Shape": "circle"
},
{
"Size": "small"
}
]
},
{
"conditionName": "cmHandleWithCpsPath",
"conditionParameters": [
{
"cpsPath": "//state[@cm-handle-state='ADVISED']"
}
]
}
]
}
With the hasAllModules condition, we can provide a list of module names. The CM Handles returned will have these module names. The parameter names must be as below with the key of each of the module names being “moduleName” where “my-module-X” is to be replaced with the name of the module to query with. The returned CM Handle must have all supplied modules. For the example request, a CM Handle will be returned if it has “my-module-1”, “my-module-2” and “my-module-3”.
{
"cmHandleQueryParameters": [
{
"conditionName": "hasAllModules",
"conditionParameters": [
{
"moduleName": "my-module-1"
},
{
"moduleName": "my-module-2"
},
{
"moduleName": "my-module-3"
}
]
}
]
}
With the hasAllProperties condition, we can provide a list of property keys and values. The CM Handles returned will have these properties. The parameter names must be as below with key and value for each property. The returned CM Handle must have all supplied properties. For the example request, a CM Handle will be returned if it has properties where there is a key of “Color” with value “yellow”, a key of “Shape” with value “circle” and a key of “Size” with value “small”.
{
"cmHandleQueryParameters": [
{
"conditionName": "hasAllProperties",
"conditionParameters": [
{
"Color": "yellow"
},
{
"Shape": "circle"
},
{
"Size": "small"
}
]
}
]
}
The cmHandleWithCpsPath condition allows any data of the CM Handle to be queried as long as it is accessible by CPS path. CPS path is described in detail in CPS Path. For this endpoint, the ancestor of CM Handles is appended automatically so that a CM Handle is always returned. For example //state[@cm-handle-state='LOCKED'] will become //state[@cm-handle-state='LOCKED']/ancestor::cm-handles. The yang model for the dmi-registry can be found in CPS Modeling under the NCMP Modeling Section. Please note that although CM Handle additional-properties are shown in the dmi-registry yang model, these are considered private properties and cannot be used to query CM Handles. Any attempt to use the additional-properties to query will return an empty array.
{
"cmHandleQueryParameters": [
{
"conditionName": "cmHandleWithCpsPath",
"conditionParameters": [
{
"cpsPath": "//state[@cm-handle-state='LOCKED']"
}
]
}
]
}
CPS Scheduled Processes
The following section is a list of the current scheduled processes running within the CPS system.
The module sync is a user configurable timed process, which is set to search for CM-Handles within CPS with an ‘ADVISED’ state. Once the CM-Handle(s) is processed by the module sync, the CM-Handle state is then set to ‘READY’, if the process completes successfully. If for any reason the module sync fails, the CM-Handle state will then be set to ‘LOCKED’, and the reason for the lock will also be stored within CPS.
The data sync is a user configurable timed process, which is set to search for CM-Handles with a sync state of ‘UNSYNCHRONIZED’. Once the CM-Handle(s) with a sync state of ‘UNSYNCHRONIZED’ is processed by the data sync, the CM-Handle sync state is then set to ‘SYNCHRONIZED’, if the process completes successfully. If the data sync fails, the CM-Handle sync state will remain as ‘UNSYNCHRONIZED’, and will be re-attempted.
The retry mechanism is a user configurable timed process, which is used to search for CM-Handles which are currently in a ‘LOCKED’ state. If the CM-Handle is ready to be retried then, the CM-Handle(s) in a ‘LOCKED’ state is processed by the retry mechanism, the CM-Handle state is then set to ‘ADVISED’. Whether the CM-Handle is ready to be retried is dependent on both the number of attempts to sync the CM-Handle, and the last update time of the CM-Handle state. With each new attempt to unlock the CM-Handle, the time until the CM-Handle can next be retried is doubled.
CPS Events
CPS-NCMP
Async events are triggered when a valid topic has been detected in a passthrough operation.
NCMP request response event schema
Event header
{
"eventId" : "001",
"eventCorrelationId" : "cps-001",
"eventTime" : "2022-09-28T12:24:21.003+0000",
"eventTarget" : "test-topic",
"eventType" : "org.onap.cps.ncmp.event.model.DmiAsyncRequestResponseEvent",
"eventSchema" : "urn:cps:org.onap.cps.ncmp.event.model.DmiAsyncRequestResponseEvent:v1",
"forwarded-Event" : { ... }
}
Forwarded-Event Payload
"Forwarded-Event": {
"eventId" : "002",
"eventCorrelationId" : "cps-001",
"eventTime" : "2022-09-28T12:24:18.340+0000",
"eventTarget" : "test-topic",
"eventType" : "org.onap.cps.ncmp.event.model.DmiAsyncRequestResponseEvent",
"eventSchema" : "urn:cps:org.onap.cps.ncmp.event.model.DmiAsyncRequestResponseEvent:v1",
"eventSource" : "org.onap.cps.ncmp.dmi",
"response-data-schema" : "urn:cps:org.onap.cps.ncmp.event.model.DmiAsyncRequestResponseEvent:v1",
"response-status" : "OK",
"response-code" : "200",
"response-data" : { ... }
}
Lifecycle Management (LCM) Event
LCM events for CM Handles are published when a CM Handle is created, deleted or another change in the cm handle state occurs.
3 possible event types:
Create
Update
Delete
The current published LCM event is based on the following schema:
Events header
Event header prototype for all event types
{
"eventId" : "00001",
"eventCorrelationId : "cmhandle-001",
"eventTime" : "2021-11-16T16:42:25-04:00",
"eventSource" : "org.onap.ncmp",
"eventType" : "org.onap.ncmp.cmhandle-lcm-event.create",
"eventSchema" : "org.onap.ncmp:cmhandle-lcm-event",
"eventSchemaVersion" : "1.0"
"event": ....
}
Events payload
Event payload varies based on the type of event.
CREATE
Event payload for this event contains the properties of the new cm handle created.
Create event payload prototype
"event": {
"cmHandleId" : "cmhandle-001",
"newValues" : {
"cmHandleState" : "ADVISED",
"dataSyncEnabled" : "TRUE",
"cmhandleProperties" : [
"prop1" : "val1",
"prop2" : "val2"
]
}
}
}
UPDATE
Event payload for this event contains the difference in state and properties of the cm handle.
Update event payload prototype
"event": {
"cmHandleId" : "cmhandle-001",
"oldValues" : {
"cmHandleState" : "ADVISED",
"dataSyncEnabled" : "FALSE",
"cmhandleProperties" : [
"prop1" : "val1",
"prop2" : "val2",
}
"newValues" : {
"cmHandleState" : "READY",
"dataSyncEnabled" : "TRUE",
"cmhandleProperties" : [
"prop1" : "updatedval1",
"prop2" : "updatedval2"
]
}
}
}
DELETE
Event payload for this event contains the identifier of the deleted cm handle.
Delete event payload prototype
"event": {
"cmHandleId" : "cmhandle-001",
}
CPS Deployment
Contents
CPS OOM Charts
The CPS kubernetes chart is located in the OOM repository. This chart includes different cps components referred as <cps-component-name> further in the document are listed below:
Please refer to the OOM documentation on how to install and deploy ONAP.
Installing or Upgrading CPS Components
The assumption is you have cloned the charts from the OOM repository into a local directory.
Step 1 Go to the cps charts and edit properties in values.yaml files to make any changes to particular cps component if required.
cd oom/kubernetes/cps/components/<cps-component-name>
Step 2 Build the charts
cd oom/kubernetes
make SKIP_LINT=TRUE cps
Note
SKIP_LINT is only to reduce the “make” time
Step 3 Undeploying already deployed cps components
After undeploying cps components, keep monitoring the cps pods until they go away.
helm del --purge <my-helm-release>-<cps-component-name>
kubectl get pods -n <namespace> | grep <cps-component-name>
Step 4 Make sure there is no orphan database persistent volume or claim.
First, find if there is an orphan database PV or PVC with the following commands:
Note
This step does not apply to ncmp-dmi-plugin.
kubectl get pvc -n <namespace> | grep <cps-component-name>
kubectl get pv -n <namespace> | grep <cps-component-name>
If there are any orphan resources, delete them with
kubectl delete pvc <orphan-cps-core-pvc-name>
kubectl delete pv <orphan-cps-core-pv-name>
Step 5 Delete NFS persisted data for CPS components
Connect to the machine where the file system is persisted and then execute the below command
rm -fr /dockerdata-nfs/<my-helm-release>/<cps-component-name>
Step 6 Re-Deploy cps pods
After deploying cps, keep monitoring the cps pods until they come up.
helm deploy <my-helm-release> local/cps --namespace <namespace>
kubectl get pods -n <namespace> | grep <cps-component-name>
Restarting a faulty component
Each cps component can be restarted independently by issuing the following command:
kubectl delete pod <cps-component-pod-name> -n <namespace>
Credentials Retrieval
Application and database credentials are kept in Kubernetes secrets. They are defined as external secrets in the values.yaml file to be used across different components as :
Below are the list of secrets for different cps components.
Component |
Secret type |
Secret Name |
|---|---|---|
cps-core |
Database authentication |
<my-helm-release>-cps-core-pg-user-creds |
cps-core |
Rest API Authentication |
<my-helm-release>-cps-core-app-user-creds |
cps-temporal |
Rest API Authentication |
<my-helm-release>-cps-temporal-app-user-creds |
cps-temporal |
Database authentication |
<my-helm-release>-cps-temporal-pg-user-creds |
ncmp-dmi-plugin |
Rest API Authentication |
<my-helm-release>-cps-dmi-plugin-user-creds |
ncmp-dmi-plugin |
SDNC authentication |
<my-helm-release>-ncmp-dmi-plugin-sdnc-creds |
The credential values from these secrets are configured in running container as environment variables. Eg: cps core deployment.yaml
If no specific passwords are provided to the chart as override values for deployment, then passwords are automatically generated when deploying the Helm release. Below command can be used to retrieve application property credentials
kubectl get secret <my-helm-release>-<secret-name> -n <namespace> -o json | jq '.data | map_values(@base64d)'
Note
base64d works only with jq version 1.6 or above.
CPS Core Pods
To get a listing of the cps-core Pods, run the following command:
kubectl get pods -n <namespace> | grep cps-core
dev-cps-core-ccd4cc956-r98pv 1/1 Running 0 24h
dev-cps-core-postgres-primary-f7766d46c-s9d5b 1/1 Running 0 24h
dev-cps-core-postgres-replica-84659d68f9-6qnt4 1/1 Running 0 24h
Note
The CPS Service will have to be restarted each time a change is made to a configurable property.
Additional CPS-Core Customizations
The following table lists some properties that can be specified as Helm chart values to configure the application to be deployed. This list is not exhaustive.
Any spring supported property can be configured by providing in config.additional.<spring-supported-property-name>: value Example: config.additional.spring.datasource.hikari.maximumPoolSize: 30
Property |
Description |
Default Value |
|---|---|---|
config.appUserName |
User name used by cps-core service to configure the authentication for REST API it exposes. This is the user name to be used by cps-core REST clients to authenticate themselves. |
|
config.appUserPassword |
Password used by cps-core service to configure the authentication for REST API it exposes. This is the password to be used by CPS Temporal REST clients to authenticate themselves. If not defined, the password is generated when deploying the application. See also Credentials Retrieval. |
Not defined |
postgres.config.pgUserName |
Internal user name used by cps-core to connect to its own database. |
|
postgres.config.pgUserPassword |
Internal password used by cps-core to connect to its own database. If not defined, the password is generated when deploying the application. See also Credentials Retrieval. |
Not defined |
postgres.config.pgDatabase |
Database name used by cps-core |
|
logging.level |
Logging level set in cps-core |
info |
config.useStrimziKafka |
If targeting a custom kafka cluster, ie useStrimziKafka: false, the config.eventPublisher.spring.kafka values below must be set. |
true |
config.eventPublisher. spring.kafka.bootstrap-servers |
Kafka hostname and port |
|
config.eventPublisher. spring.kafka.consumer.client-id |
Kafka consumer client id |
|
config.eventPublisher. spring.kafka.security.protocol |
Kafka security protocol. Some possible values are:
|
|
config.eventPublisher. spring.kafka.properties. sasl.mechanism |
Kafka security SASL mechanism. Required for SASL_PLAINTEXT and SASL_SSL protocols. Some possible values are:
|
Not defined |
config.eventPublisher. spring.kafka.properties. sasl.jaas.config |
Kafka security SASL JAAS configuration. Required for SASL_PLAINTEXT and SASL_SSL protocols. Some possible values are:
|
Not defined |
config.eventPublisher. spring.kafka.ssl.trust-store-type |
Kafka security SASL SSL store type. Required for SASL_SSL protocol. Some possible values are:
|
Not defined |
config.eventPublisher. spring.kafka.ssl.trust-store-location |
Kafka security SASL SSL store file location. Required for SASL_SSL protocol. |
Not defined |
config.eventPublisher. spring.kafka.ssl.trust-store-password |
Kafka security SASL SSL store password. Required for SASL_SSL protocol. |
Not defined |
config.eventPublisher. spring.kafka.properties. ssl.endpoint.identification.algorithm |
Kafka security SASL SSL broker hostname identification verification. Required for SASL_SSL protocol. Possible value is:
|
Not defined |
config.additional. notification.data-updated.topic |
Kafka topic to publish to cps-temporal |
|
config.additional. notification.data-updated.filters. enabled-dataspaces |
Dataspaces to be enabled for publishing events to cps-temporal |
|
config.additional. notification.data-updated.enabled |
If asynchronous messaging, user notifications, and updated event persistence should be enabled |
|
config.additional. notification.async.executor. core-pool-size |
Core pool size in asynchronous execution of notification. |
|
config.additional. notification.async.executor. max-pool-size |
Max pool size in asynchronous execution of notification. |
|
config.additional. notification.async.executor. queue-capacity |
Queue Capacity in asynchronous execution of notification. |
|
config.additional. notification.async.executor. wait-for-tasks-to-complete-on-shutdown |
If the executor should wait for the tasks to be completed on shutdown |
|
config.additional. notification.async.executor. thread-name-prefix |
Prefix to be added to the thread name in asynchronous execution of notifications. |
|
config.additional. spring.datasource.hikari. maximumPoolSize |
Specifies number of database connections between database and application. This property controls the maximum size that the pool is allowed to reach, including both idle and in-use connections. |
|
Additional CPS-NCMP Customizations
config.dmiPluginUserName |
User name used by cps-core to authenticate themselves for using ncmp-dmi-plugin service. |
|
config.dmiPluginUserPassword |
Internal password used by cps-core to connect to ncmp-dmi-plugin service. If not defined, the password is generated when deploying the application. See also Credentials Retrieval. |
Not defined |
config.ncmp.timers .advised-modules-sync.sleep-time-ms |
Specifies the delay in milliseconds in which the module sync watch dog will wake again after finishing. |
|
config.ncmp.timers .locked-modules-sync.sleep-time-ms |
Specifies the delay in milliseconds in which the retry mechanism watch dog will wake again after finishing. |
|
config.ncmp.timers .cm-handle-data-sync.sleep-time-ms |
Specifies the delay in milliseconds in which the data sync watch dog will wake again after finishing. |
|
CPS-Core Docker Installation
CPS-Core can also be installed in a docker environment. Latest docker-compose is included in the repo to start all the relevant services. The latest instructions are covered in the README.
CPS Release Notes
Contents
Version: 3.1.5
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:3.1.5 |
Release designation |
3.1.5 Kohn |
Release date |
2022 October 25 |
Bug Fixes
CPS-1312 CPS(/NCMP) does not have version control
Known Limitations, Issues and Workarounds
System Limitations
For upgrading, CPS uses Liquibase for database upgrades. CPS/NCMP currently only supports upgrading from Liquibase changelog 11 to Liquibase changelog 16. This is from commit CPS-506: List all known modules and revision to CPS-1312: Default CMHandles to READY during upgrade or from ONAP release Honolulu to Kohn.
Version: 3.1.4
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:3.1.4 |
Release designation |
3.1.4 Kohn |
Release date |
2022 October 5 |
Bug Fixes
Version: 3.1.3
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:3.1.3 |
Release designation |
3.1.3 Kohn |
Release date |
2022 September 29 |
Bug Fixes
None
Version: 3.1.2
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:3.1.2 |
Release designation |
3.1.2 Kohn |
Release date |
2022 September 28 |
Bug Fixes
None
Version: 3.1.1
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:3.1.1 |
Release designation |
3.1.1 Kohn |
Release date |
2022 September 28 |
Bug Fixes
None
Security Notes
Fixed Security Issues
CPS-1226 Security bug in the logs
Version: 3.1.0
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:3.1.0 |
Release designation |
3.1.0 Kohn |
Release date |
2022 September 14 |
Features
CPS-340 Patch and update the root data node
CPS-575 Write data for cmHandle using ncmp-datastores:passthrough-running (NCMP.)
CPS-731 Query based on Public CM Properties
CPS-828 Async: NCMP Rest impl. including Request ID generation
CPS-829 Async: Internal message topic incl. basic producer & Consumer
CPS-830 DMI-NCMP Asynchronously Publish Response Event to Client Topic
CPS-869 Apply Standardized logging fields to adhere to ONAP Best practice REQ-1072
CPS-870 Align CPS-Core output with SDN-C output (add module name)
CPS-875 CM Handle State: Watchdog-process that syncs ‘ADVISED’ CM Handles
CPS-877 CM Handle State: Exclude any CM-Handles from queries/operations that are not in state ‘READY’
CPS-899 Start and stop sessions on Java API
CPS-909 Separate NCMP endpoint for ch/{cm-handle}/properties and ch/{cm-handle}/state
CPS-917 Structured Errors response for passthrough use-cases in NCMP
CPS-953 Update maven deploy plugin version
CPS-977 Query CM Handles using CpsPath
CPS-1000 Create Data Synchronization watchdog
CPS-1016 Merge 2 ‘query’ end points in NCMP
CPS-1034 Publish lifecycle events for ADVISED , READY and LOCKED state transition”
CPS-1064 Support retrieval of YANG module sources for CM handle on the NCMP interface
CPS-1099 Expose simplified ‘external’ lock reason enum state over REST interface
CPS-1101 Introducing the DELETING and DELETED Cmhandle State
CPS-1102 Register the Cmhandle Sends Advised State notification.
CPS-1133 Enable/Disable Data Sync for Cm Handle
CPS-1136 DMI Audit Support (get all CM Handles for a registered DMI)
Bug Fixes
CPS-896 CM Handle Registration Process only partially completes when exception is thrown
CPS-957 NCMP: fix getResourceDataForPassthroughOperational endpoint
CPS-1020 DuplicatedYangResourceException error at parallel cmHandle registration
CPS-1056 Wrong error response format in case of Dmi plugin error
CPS-1067 NCMP returns 500 error on searches endpoint when No DMi Handles registered
CPS-1085 Performance degradation on ncmp/v1/ch/searches endpoint
CPS-1088 Kafka consumer can not be turned off
CPS-1097 Unable to change state from LOCKED to ADVISED
CPS-1126 CmHandle creation performance degradation
CPS-1175 Incorrect response when empty body executed for cmhandle id-searches
CPS-1179 Node API - GET method returns invalid response when identifier contains ‘/’
CPS-1212 Additional Properties for CM Handles not included when send to DMI Plugin
CPS-1217 Searches endpoint gives back empty list however there are already available cmhandles
CPS-1218 NCMP logs are flooded with SyncUtils logs
Known Limitations, Issues and Workarounds
System Limitations
Having ‘[’ token in any index in any list will have a negative impact on the search functions leaf-conditions and text()-condition. Example of an xpath that would cause problems while using cps-path queries : /parent/child[@id=’id[with]braces’]
Known Vulnerabilities
None
Workarounds
None
Security Notes
Fixed Security Issues
CPS-963 Liquibase has got serious vulnerability, upgrade required
Known Security Issues
None
Version: 3.0.1
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:3.0.1 |
Release designation |
3.0.1 Jakarta |
Release date |
2022 April 28 |
Bug Fixes
CPS-961 Updated ANTLR compiler version to 4.9.2 to be compatible with runtime version
Version: 3.0.0
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:3.0.0 |
Release designation |
3.0.0 Jakarta |
Release date |
2022 March 15 |
Features
CPS-559 Define response objects (schemas) in cps-ncmp
CPS-636 Update operation for datastore pass through running
CPS-638 Delete operation for datastore pass through running
CPS-677 Support ‘public’ Cm Handle Properties
CPS-741 Re sync after removing cm handles
CPS-777 Ensure all DMI operations use POST method
CPS-780 Add examples for parameters, request and response in openapi yaml for cps-core
CPS-789 CPS Data Updated Event Schema V2 to support delete operation
CPS-791 CPS-Core sends delete notification event
CPS-817 Create Endpoint For Get Cm Handles (incl. public properties) By Name
CPS-837 Add Remove and Update properties (DMI and Public) as part of CM Handle Registration update
Bug Fixes
CPS-762 Query cm handles for module names returns incorrect cm handle identifiers
CPS-788 Yang Resource formatting is incorrect
CPS-783 Remove cm handle does not completely remove all cm handle information
CPS-841 Upgrade log4j to 2.17.1 as recommended by ONAP SECCOM
CPS-856 Retry mechanism not working for concurrent CmHandle registration
CPS-867 Database port made configurable through env variable DB_PORT
CPS-886 Fragment handling decreasing performance for large number of cmHandles
CPS-887 Increase performance of cmHandle registration for large number of schema sets in DB
CPS-892 Fixed the response code during CM-Handle Registration from 201 CREATED to 204 NO_CONTENT
CPS-893 NCMP Java API depends on NCM-Rest-API (cyclic) through json properties on Java API
Known Limitations, Issues and Workarounds
System Limitations
Null can no longer be passed within the dmi plugin service names when registering a cm handle, as part of CPS-837 null is now used to indicate if a property should be removed as part of cm handle registration.
The Absolute path to list with integer key will not work. Please refer CPS-961 for more information.
Known Vulnerabilities
None
Workarounds
Instead of passing null as a value within the dmi plugin service names, remove them from the request completely, or pass an empty string as the value if you do not want to include names for these values.
Security Notes
Fixed Security Issues
None
Known Security Issues
None
Version: 2.0.4
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:2.0.4 |
Release designation |
2.0.4 Istanbul |
Release date |
2022 Feb 09 |
Bug Fixes
Version: 2.0.3
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:2.0.3 |
Release designation |
2.0.3 Istanbul |
Release date |
2022-07-01 |
Bug Fixes
CPS-841 Update log4j version to 2.17.1 due to security vulnerability
Version: 2.0.2
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:2.0.2 |
Release designation |
2.0.2 Istanbul |
Release date |
2021-16-12 |
Bug Fixes
CPS-820 Update log4j version due to security vulnerability
Version: 2.0.1
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:2.0.1 |
Release designation |
2.0.1 Istanbul |
Release date |
2021-14-10 |
Bug Fixes
Known Limitations, Issues and Workarounds
System Limitations
Limitations to the amount of child nodes that can be added to the fix above. The current limit is 3.
Known Vulnerabilities
CPS-725 fix sample docker compose of cps/ncmp and onap dmi plugin
Workarounds
Add recursive method to save list node data to loop through all corresponding child nodes.
Security Notes
Fixed Security Issues
CPS-581 Remove security vulnerabilities
Known Security Issues
None
Version: 2.0.0
Abstract
This document provides the release notes for Istanbul release.
Release Data
CPS Project |
|
Docker images |
onap/cps-and-ncmp:2.0.0 |
Release designation |
2.0.0 Istanbul |
Release date |
2021-14-09 |
Features
Register DMI-Plugins with NCMP for CM Handle registrations.
Update, Create and Remove CM Handles.
Add support for retrieving and writing CM Handle data through NCMP datastores.
Automatic retrieval and caching of model information for CM Handles within NCMP.
Deliverables
Software Deliverables
Repository |
SubModules |
Version & Docker Image (if applicable) |
|---|---|---|
cps |
onap/cps-and-ncmp-proxy:2.0.0 |
Bug Fixes
CPS-310 Data schema migration from Honolulu to Istanbul is failing
CPS-316 Xpath cannot be created for augmentation data node
CPS-336 Ends-with functionality in cpsPath does not conform with standard xPath behavior
CPS-345 Leaf String value comparison matches mix of single and double quotes
CPS-357 cps-review-verification-maven-master Jenkins job is failing when running csit test
CPS-367 Get descendent does not support xpaths that end in list values
CPS-377 Init ran model validation is failing error details are not provided
CPS-422 REST 404 response returned instead of 400 for POST/PUT/PATCH request types
CPS-450 Datanode query using full path to node causes NPE
CPS-451 cps-ran-schema-model@2021-01-28.yang missing root container
CPS-464 Request to update node leaves (patch) responds with Internal Server Error
CPS-465 Request to update node leaves (patch) responds with json parsing failure
CPS-466 Concurrent requests to create schema sets for the same yang model are not supported
CPS-479 Get Nodes API does not always return the object from the root
CPS-500 Special Character Limitations of cpsPath Queries
CPS-501 Put DataNode API has missing transaction and error handling for concurrency issues
CPS-524 Issue with CPSData API to add an item to an existing list node
CPS-560 Response from cps query using text() contains escape characters
CPS-566 Can’t access grandparent node through ancestor axis
CPS-573 /v1/ch/PNFDemo1/modules returning 401 unauthorised.
CPS-587 cps-ncmp-service NullpointerException when DmiPluginRegistration has no additionProperties
CPS-591 CPS-Core Leaf stored as integer is being returned from DB as float
CPS-601 CPS swagger-ui does not show NCMP endpoints
CPS-616 NCMP base path does not conform to agreed API URL
CPS-630 Incorrect information sent when same anchor is updated faster than notification service processes
CPS-635 Module Resource call does not include body
This document provides the release notes for Istanbul release.
Summary
Following CPS components are available with default ONAP/CPS installation.
Platform components
CPS (Helm charts)
Service components
CPS-NCMP
CPS-Temporal
DMI-Plugin
Additional resources that CPS utilizes deployed using ONAP common charts
Postgres Database
- Below service components (mS) are available to be deployed on-demand.
CPS-TBDMT
Under OOM (Kubernetes) all CPS component containers are deployed as Kubernetes Pods/Deployments/Services into Kubernetes cluster.
Known Limitations, Issues and Workarounds
System Limitations
Limitations to the amount of child nodes that can be added to the fix above. The current limit is 3.
Known Vulnerabilities
Workarounds
Add recursive method to save list node data to loop through all corresponding child nodes.
Security Notes
Fixed Security Issues
CPS-249 Exception stack trace is exposed
Known Security Issues
CPS-581 Remove security vulnerabilities
Test Results
Integration tests
Version: 1.0.1
Release Data
CPS Project |
|
Docker images |
onap/cps-and-nf-proxy:1.0.1 |
Release designation |
1.0.1 Honolulu |
Release date |
2021-04-09 |
Bug Fixes
CPS-706 Get moduleschema/yangresouce endpoint not working
CPS-276 Improve error reporting for invalid cpsPath on Queries
CPS-288 Move security configuration to the application module
CPS-290 Internal Server Error when creating the same data node twice
CPS-292 Detailed information is missing to explain why data is not compliant with the specified YANG model
CPS-300 Not able to create data instances for 2 different anchors using the same model
CPS-304 Use ONAP recommended base Java Docker image
CPS-308 Not able to upload yang models files greater than 1MB
Security Notes
Fixed Security Issues
CPS-249 Exception stack trace is exposed
Known Security Issues
Security Waiver Security - Expose external endpoints with https
Version: 1.0.0
Abstract
This document provides the release notes for Honolulu release.
Summary
Following CPS components are available with default ONAP/CPS installation.
Platform components
CPS (Helm charts)
Service components
CPS Core
Additional resources that CPS utilizes deployed using ONAP common charts
Postgres Database
- Below service components (mS) are available to be deployed on-demand.
CPS-TBDMT
Under OOM (Kubernetes) all CPS component containers are deployed as Kubernetes Pods/Deployments/Services into Kubernetes cluster.
Release Data
CPS Project |
|
Docker images |
Refer Deliverable |
Release designation |
1.0.0 Honolulu |
Release date |
2021-03-11 |
Features
Configuration Persistence Service is a model driven persistence solution for data described by YANG models. CPS has been driven by the needs of the E2E Networking Slicing use case. It currently supports basic (rw) persistence and simple queries. It also provides MVP support for network data access using simulated data.
Deliverables
Software Deliverables
Repository |
SubModules |
Version & Docker Image (if applicable) |
|---|---|---|
cps |
onap/cps-and-nf-proxy:1.0.0 |
Known Limitations, Issues and Workarounds
CPS-249 Exception stack trace is exposed
CPS-264 Unique timestamp is missing when tagging docker images.
Methods exposed on API which are yet not implemented : deleteAnchor, getNodesByDataspace & deleteDataspace.
CPS-465 & CPS-464 Update data node leaves API does not support updating a list element with compound keys.
System Limitations
None
Known Vulnerabilities
None
Workarounds
Documented under corresponding jira if applicable.
Security Notes
Fixed Security Issues
- CPS-167 -Update CPS dependencies as Required for Honolulu release
Upgrade org.onap.oparent to 3.2.0
Upgrade spring.boot to 2.3.8.RELEASE
Upgrade yangtools to 5.0.7
Known Security Issues
Weak Crytography using md5
Risk seen in Zip file expansion
Known Vulnerabilities in Used Modules
None
CPS code has been formally scanned during build time using NexusIQ and all Critical vulnerabilities have been addressed, items that remain open have been assessed for risk and determined to be false positive.
Test Results
References
For more information on the ONAP Honolulu release, please see:
Quick Links: