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
| # | Assumption | Reasoning/Justification |
|---|---|---|
| 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 |
Topic Areas
Issues & Decisions
(closed issue will be marked in green)
Topic Area | Priority | Issue slogan/link | Brief description | Ready to discuss | Decision |
|---|---|---|---|---|---|
| 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? | Yes | 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. |
| 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. | 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. |
| 4,5 | MEDIUM | 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 | Yes | |
| 4,5 | MEDIUM | 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). | Yes | |
| 1,3 | LOW | 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? | No | |
| 1,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 | No | |
| 1 | LOW | Specifiy and configure CPS behavior | 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 | No | |
| 1 | MEDIUM | Existing Yang Parser | Is there an existing Yang Parser in ONAP an/or OpenDayLight that can be used for C&PS | No | |
| N/A | MEDIUM | 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. | Yes | |
| N/A | MEDIUM | Common information model, Data lake and Access control, | How will the CPS help with managing coupling between ONAP components that make use of data lake and common information model |