The current API is a basic hard coded REST interface with specific methods supporting 2 object types and a few operations. Although extensible it will be hard to keep the new proposed interface backward compatible with the original API.
Yes
--
No Compatibility. Either a adapter will be provided later of some resource will be set reserved to migrate the existing client to the new service when available.
The access interface needs to suit the users of the data. It must also acknowledge the underlying data structure.
There are two main options: Providing behavior interfaces on a logical representation of the data; Providing behavior interfaces on the CPS and explicitly providing reference to the data
Yes
--
Option B, Access methods on the CPS; Data object provides context to those methods.
The data that is read from and written to the CPS must comply with a known format. This is relevant to both Java and REST interfaces. The choices here are to provide generic objects/documents, or highly typed (using model info).
The CPS will be model driven, which means that new models can be added to the CPS. How will models be introduced to the CPS from other components in the ONAP system or the network?
No
--
There will be a single way to add a YANG model to CPS. This is done through the CPS model life-cycle management interface.
As the network functions evolve, new versions of models will be introduced that will replace existing models for new versions of the NF. These new versions will need to co-exist alongside existing versions, such that different NF versions can be modelled using the appropriate model version
Postponed to Decisions for future releases, see #1 table below
The behavior of the CPS needs to be driven by a model. The native model language of CPS is YANG. There are several mechanisms available to achieve this need. One needs to be selected
Postponed to Decisions for future releases, see #2 table below
Is there an existing Yang Parser in ONAP an/or OpenDayLight that can be used for C&PS
No
: yes; ODL's Yang Tools. This is already widely used in OMAP Java Projects (for more details follow link in prev. column)
PYang - a standard python tool for processing Yang model; benefit over ODL; conver to XML to perform own processing. Yang is a simple tree data structure. difficulty is extending/augmentation. PYang will come up with representation of data. Locked into Java vs a table. A Yang model can be served in V1/V2. Version management of Yang models. Augmentation to deal with modification of V1 of a model; upgrade from V1 > V2. maintaining schemas (Yang model) can ingest data in either V1 or V2 & serve it in V1/V2.
Yes
For the Java-based service ODL's Yang Tools will be used. For specific use-cases it might be more suitable yo use Python and PYang e.g. Model Visualization.
9
N/A
Status
colour
Yellow
Grey
title
MEDIUM
Agreed
Location of PoC Code
Dan Timony suggested to use and existing CCSDK repo, he mentioned ccsdk/features. As long as the PoC remains completely independent and doesn't affect delivery of existing artifacts in the same repo.
How will the CPS help with managing coupling between ONAP components that make use of data lake and common information model
--
We will start with Architectural Approach A in the PoC with the aim of fully supporting Architectural Approach C.
I.e. access to the data lake will be conditional on permission granted by the data owner. In the PoC we will not implement the permission granting mechanism
It needs to be clear to users the level of atomic operations supported by the CPS.
Transactions are performed sequentially and atomically (one at a time). As an external user you have a Java interface (with a dedicated mSvc) & REST interface. It is up to the user of C&PS to specify the order of changes in their input document.
--
The CPS will not use an external transaction manager. Where the underlying DBMS provides transactions, these will be exposed by the SPI and used by the CPS core library.
The CPS core library will expose a simple session concept to co-deployed modules. This will enable fine grained control of the order of changes. This will help ensure that complex validation (e.g. WHEN clause) succeeds.
For REST users, the session concept will not be exposed. Where documents representing several operations are input, the CPS will follow the order of the input document, and fail fast. Any failures will be abandoned (if the underlying DBMS supports transactions) and a failure response will be returned to the REST user.
Discussion about usage of DCAE Data Exposure Service (DES) concept.
krishna moorthy presented on the MAPPER SERVICE at CPS meeting and
API Mapp/DES like transformer:TemplateBasedDataModelTransformer will be developed for this purpose. Initially a PoC in CPS but it might become a separate component
Discuss the XPath adaptation to address data fragments in a context of Yang Modules revisions variety
For now there is no need to store full module identifier in the xpath field. The namespace, revision, parent module context will be taken into account using references through dedicated fields (module_id, parent_id).
Limitation determined: only keyed collections are supported. No node identification by index is expected.
The attribute order for composite keys to be handled as dedicated task. Both requested xpath and stored one expected to sort key attributes by attribute (leaf) name
The module-set to module relationship, module-set immutability, taking into account cross-impact of modules on module-set persistence
Module-set is immutable collection of modules. None of modules can be added or removed independently, only as part of module-set insert or delete. Also module-set itself does not assume updates for now.
The module-set uniqueness within a dataspace to be identified by string identifier now, also by content later
The modules are stored as source definition, no processing on module entity persistence. On data validation it's expected the schema context (representing effective models) to be compiled with taking into account all the modules from the module-set.
The persistence of pre-compiled context (as module-set content) or caching it or other performance optimizations to be discussed later.
The goal for MVP is to deploy alternative 2 here (CPS core and NXF-REST proxy in one service) with OOM. With a possible inclusion of Temporal DB RETS interface when available (alternative 3)
generate one cps - Nf - cpsAndxN docker image (exact names to be agreed through code review)
Docker image deployment
deploy xNF docker image
DB integration
OOM Db provided
external Db
Certificates
Ingress
Provide our certificates
Application configuration file location
It should live under OOM
it should live under CPS Application module
Yes
Agreed on
Docker image deployment
Tony Finnerty asked to ensure that the DB Integration is clearly documented in source and deployment documentation to ensure it stays de-coupled and can easily be substituted
Application configuration file location
Was contentious but the deciding factors where user-configurability and most common use pattern in ONAP. We still have the option to add a 'default' configuration option in CPS Application Module
24
Status
colour
Yellow
title
MEDIUM
Update requirements for E2E NetworkSlicing UseCase
The preferred methods for updating are:
Update a DataNode by providing a new DataNode with all attributes but with child-references
Add a DataNode to a yang-list (this might container children, only looked at one case so far where this didn't apply)
Remove a DataNode from a Yang List (this will automatically remove any descendants too)
Any Interface impacts of this should be clearly document in Open API Yaml
As the network functions evolve, new versions of models will be introduced that will replace existing models for new versions of the NF. These new versions will need to co-exist alongside existing versions, such that different NF versions can be modelled using the appropriate model version
The behavior of the CPS needs to be driven by a model. The native model language of CPS is YANG. There are several mechanisms available to achieve this need. One needs to be selected
5G Service Modeling Use Case and interactions with C&PS.
(1) Registration system - Creating a system for registration discovery & management mechanism to allow for coordination and inter-operation of micro-services who want access to common data. Models are also stored in the registry.
No
The scope of the CPS will include a 'Registry Service'
More good discussion . Needs separate meeting to clarify
