Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

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?

Decision

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

Details

There are many ways in which models can be added. These are not mutually exclusive. They do need to be understood and agreed.

  1. xNF model (external) delivered in vendor package on-boarded in SDC
  2. Model retrieved directly from xNF (external model)
  3. Model provided by application (application model)
Option A (Source: Vendor package)

In line with the concept of model ownership, the Mirror Service is designated owner of xNF models.

Design time activities are shaded.

Option B (Source: xNF)

In line with the concept of model ownership, the Mirror Service is designated owner of xNF models.

Option C (Source: ONAP component)

Discussion

As there are several ways in which a model may be added to ONAP, the sensible approach is to have a single way to add a model to CPS. This is the CPS model life-cycle interface.

Depending on the source of the model, different ONAP components will be involved in the delivery of models to CPS. For example:

  • SDC publishes on-boarded packages to DMaaP. Some CPS process must subscribe to DMaaP, extract the relevant models from the package/archive and then use the CPS model life-cycle interface to add it to CPS.
  • SDNC reads a model directly from the xNF, then uses the CPS model life-cycle interface to add it to CPS.
  • An application that wants to store data in the CPS must first use the (one-time only action) the CPS model life-cycle interface to add it to CPS.
  • No labels