Issues decisions and assumptions

1

The 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.

2

The 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.

3

The native model language of the CPS will be YANG

Industry momentum towards YANG

IETF RFC, widely supported

Superset of most language capabilities

4

The PoC will use PostgreSQL as the DBMS

None, other than one is required

1

4

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.

2

5

Agreed

Backward Compatibility with Config DB

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.

--

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.

3

4,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.

4

4,5

Agreed

Data Representation

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).

• Edit

--

Option A. Data will be represented as documents (REST) and or generic objects (glorified maps in Java)

5

1,3

Agreed

Flow of models into the system

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?

--

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

6

1,3

POSTPONED

Upgrade of models

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

7

1

POSTPONED

Specifiy and configure CPS behavior

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

8

1

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.