High Level Design (PoC)

The purpose of the page is to:

1. Design the Model Driven CPS PoC REQ-384 - Getting issue details... STATUS
2. Start the design of a stand-alone CPS
3. Engage with the CPS community on the design of the stand-alone CPS
4. Review with the ARCHCOM to ensure broad ONAP community awareness and agreed direction

PoC Overview Diagram

Topic Areas

Scope

Base scope

• Read/write persisted Configuration Management data:
  • defined by xNF (simple YANG model), published as YANG
• Models deployed @ runtime with no ONAP platform impacts or LCM events
• Show the benefits in terms of constraint validation, access and upgrade

Stretch target

Adapt behavior of CPS on read/write based on information in the model:

• Change notification emissions driven by the model
• Interaction with temporal data store, synergize with State Management PoC
• Volatile/prolific xNF data read-through (e.g. state data) – may be used to support histogram
• Model made available to CPS (Configuration and Persistency Service) using existing onboarding via SDC
• Provide some indication of dimension and user access characteristics that will be provided by CPS

Proof points

• Demonstrate Create/read operations using YANG fragments against a CPS backed by very simple schema / schema-less repository
• Demonstrate ability to deploy / upgrade YANG fragments at run-time
• Demonstrate CPS behavior driven by YANG model
• Provide architecture vision and roadmap for a target architecture, supported use cases, non-functional requirements towards an ONAP Project

Out of scope

• Automating the ingestion of models from SDC or controller (unless we get to it in the stretch target). The model LCM interface will be exercised manually during the PoC.
• Syncing with A&AI. The PoC will work on a fixed topology

High Level Design

Context of CPS

C4 diagram of main components

Logical view of the CPS as a project

The blue software encapsulates the handling of models and data related to xNF (mirrored data). This implementation is not required to prove the model driven aspects of the CPS.

The pink software encapsulates the integration with other data stores. This is being taken by the temporal DB PoC. This PoC needs to provide a feed of change notifications for any joint demonstrations. Configuring the parts of the model that will emit change notifications is part of the stretch goal.

Model handling

Below a simplified view of model handling artifacts and their relationships.

The run-time artifacts are shaded (orange). A typical simplified flow:

• A document representing xNF data is given to the CPS.
• It will parse (and validate) the document,
• Map data to the generic DB schema and store data.

In order for this to work:

• The document must be compliant to an xNF schema model. This schema model describes the structure of the data and any constraints that need to be checked to ensure integrity.
• The xNF schema model must be written in YANG. This language describes syntax and capabilities (basic concepts).
• A Yang parser is required to interpret documents compliant with the YANG language. The parser is dependent on the language.
• To store data in a DBMS, typically a schema is required. This is denoted above as, 'Generic schema model'.
• Obviously the xNF schema model and the Generic schema model are not the same. Therefor a mapping is required. Depending on how simple/generic/abstract the generic schema model, the mapping may be coupled with either the language or the xNF schema model. One of the aims of the PoC is to be agnostic to the xNF model at run-time, thus the mapping is made to the YANG language.
• To support multiple container run-times (Java, Python, Go, Rust, ...) for the CPS, the mapping is described in a 'Language Capability Map'.
• The model mapper depends on the language capability map and the Yang parser (in particular the java representation of the language features).

Model ingestion

Model ingestion is subject to a design discussion. See below. This section will be updated when that discussion has been concluded and a decision made.

Note that for the purposes of the PoC, model ingestion will be via a model life-cycle REST interface.

Model upgrade

T.B.D. See Upgrade of models for discussion and decision

Backward compatibility

See decision for more information. Compatibility will be provided by either a dedicated component, or ONAP applications depending on legacy interfaces will be updated. This will depend on resources.

Detailed design

Key sequences/flows

Add a model

Store data (including validation)

Read data

Reading data is very similar to storing data. The uuid of the model instance is assumed. Validation is not needed. Queries will need to be processed and mapped to DB technology specifics.

Upgrade a model

T.B.D. Needs to wait until upgrade behavior is specified.

Adapt change notification behavior as described in model

T.B.D. Show how the model spec is used to control interactions between CPS Core and CPS Notification

Interfaces

Style and payload structure

Pending decisions: Data Representation and Interface style

REST payload structure

Java payload structure

Access methods

Service Provider Interface (SPI)

T.B.D. An internal interface that defines how the CPS Core will interact with the DBMS. The design of the SPI will be informed by agreed CPS behavior and minimum requirements for the DBMS.

The SPI is required to ensure that different DB technologies can be used in different deployments.

Behavior

T.B.D.: Eventual consistency; Data integrity guarantees; Fast failure; Progress; Cancellation;

REST

Will be specified as part of the PoC execution, and updated/referenced from here

This will follow REST rules and guidelines as defined by ONAP documentation (TODO: add link)

Java

Will be specified as part of the PoC execution, and updated/referenced from here

Decision reference

Issues decisions and assumptions