Introduction

This page summarizes issues (documented in child pages) and the decisions/direction taken.

Decisions/direction is discussed in the child pages, and ratified during the weekly meeting.

Assumptions

#AssumptionReasoning/Justification
1The CPS stand-alone access interface technology will be REST

This is common practice in ONAP.

There is a drive to harmonize publication and documentation of component interfaces.

2The CPS internal core implementation will be Java

Alternative language bindings will be possible (explicitly enabled by the architecture).

The level of resources available indicates that a single implementation should be pursued first.

Where other language run-times need access to data they may use the REST data access interfaces.

3The native model language of the CPS will be YANG

Industry momentum towards YANG

IETF RFC, widely supported

Superset of most language capabilities

4The PoC will use PostgreSQL as the DBMSNone, other than one is required

Topic Areas

Issues & Decisions PoC & Honolulu

(closed issue will be marked in green)

#

Topic

Area

PriorityIssue slogan/linkBrief descriptionReady to discussDecision
14

AGREED

Integration pattern for current, historical, temporal, timeseries, etc.

The CPS project proposal covers multiple types of storage.

How will it integrate several DBMS technologies to support these different needs?

--Option C. Loose coupling. The focus of the PoC will be on current storage and model driven notifications to drive data towards other data stores.
25


AGREED

Backward Compatibility with Config DBThe 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.--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.
34,5

AGREED

Interface style

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

--Option B, Access methods on the CPS; Data object provides context to those methods.
44,5

AGREED

Data RepresentationThe 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).--Option A. Data will be represented as documents (REST) and or generic objects (glorified maps in Java)
51,3AGREED


Flow of models into the systemThe 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?--

There will be a single way to add a YANG model to CPS. This is done through the CPS model life-cycle management interface.

There are three ways in which the ONAP platform can add models. See details in Flow of models into the system

61,3POSTPONED


Upgrade of models

Postponed to Decisions for future releases, see #1 table below



71POSTPONED


Specifiy and configure CPS behaviorPostponed to Decisions for future releases, see #2 table below

81

AGREED

Existing Yang Parser

Is there an existing Yang Parser in ONAP an/or OpenDayLight that can be used for C&PS: 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. 

YesFor 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. 
9N/A

AGREED

Location of PoC CodeDan 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.--ccsdk/features, see  https://gerrit.onap.org/r/c/ccsdk/features/+/110385 (awaiting approval)
10N/A

AGREED

Common information model, Data lake and Access controlHow 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

114,5

AGREED

Transactional behavior

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.

(Rest of the Page is accepted)

125

POSTPONED

Model discovery at run-time

Postponed to Decisions for future releases, see #1 table below

No


135

AGREED

CCSDK-2870 DP: CPS REST API Documentation

Discuss Rest API 

Yes
14

AGREED

CPS & DCAE DES concept sharing

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
155

AGREED

Java API Wiki

SPI Wiki

Discuss the Java API and SPI wiki. Both pages include javadoc and a link to the gerrit repo.Yes
161,5AGREED


Yang modules to XPath format adaptationDiscuss 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

171,5

AGREED

Operating with Module Sets (groups of modules)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.

18

AGREED

ModuleSet content persistence proposalThe moduleset persistence approach, artifact/entity naming

Module Set sources (yang files) to be stored on a unique content basis.
Uniqueness of a content to be identified using MD5 checksum.

To rename: 
Module Set → Schema Set
Yang File → Yang Resource

19

AGREED

CPS Logging ConfigDiscuss issues/decisions in relation to logging in CPS.

20

AGREED

Decouple Anchor from Fragment proposal

Discuss the necessity of persisting anchors and data fragments at same table


Agreed as reasonable ,  implemented via 
CPS-161 - Getting issue details... STATUS

21

AGREED

xNF Proxy MVP Delivery clarification / Deployment OPtions

Discuss and clarify the expectations and implementation approach on subject.

Especially re. deployment options with SpringBoot application(s)


22

MEDIUM

Data update by xpath options

Discuss and clarify:

  • addressing the node and data format for update requests vs insert requests
  • partial data storage
  • db schema elements seems extra
  • parameters naming: cps-path vs xpath, include-descendants defaults to confirm
Yes
23

AGREED

CPS-175 OOM Integration

CPS-175 - Getting issue details... STATUS


Docker image generation

  • generate 3 types of docker image (cps - xNf - cpsAndxN)
  • 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

MEDIUM

Update requirements for E2E NetworkSlicing UseCaseThe preferred methods for updating are:
  1.  Update a DataNode by providing a new DataNode with all attributes but with child-references
  2. Add a DataNode to a yang-list  (this might container children, only looked at one case so far where this didn't apply)
  3. 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

Yes

Issues & Decisions Istanbul & Later


#

Topic

Area

PriorityIssue slogan/linkBrief descriptionReady to discussDecision
11,3

MEDIUM

Upgrade of models

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

Discuss with Christophe Closset (SDC)


No
21

LOW

Specifiy and configure CPS behaviorThe 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 selectedNo
35

MEDIUM

Model discovery at run-time

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

  • No labels