Requirement:
This is to investigate the CPS participant implementation in CLAMP to interact with CPS-Core component in ONAP.
The participant should be capable of creating and querying dataspace, schemasets and anchors in CPS-Core based on the incoming requests. The CPS data can be used by other components in Automation Composition via the CPS participant.
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-Core Modeling:
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.
Open Api specification for CPS-Core:
Feasibility of using Http participant for CPS:
Http participant uses spring webclient to asynchronously execute http requests and prints the response in ACM.
CPS-Core exposes REST endpoints for creating and querying CPS data which can be invoked by http participant with few limitations.
Limitations:
- Creating Schema set
Creating schema set requires sending multipart file (yang model) in the REST request which is not supported by http participant.
POST: /v2/dataspaces/{dataspace-name}/schema-sets