Reference Material

• Jira
  server ONAP JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 425b2b0a-557c-3c0c-b515-579789cceedb key CPS-333

• Jira
  server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key REQ-717

• Release Planning: Istanbul
• https://wiki.onap.org/download/attachments/93006150/CPS-NCMP-Design.pptx?version=1&modificationDate=1614348138000&api=v2

Open Issues & Decisions

Istanbul Roadmap

Priorities & Scope for Istanbul Release

Scenario Scope In Istanbul

This scenario will demonstrate configuration management using NCMP.

There should be following functional requirements need to be fulfilled

1. Add/remove *CM-Handle by using *DMI (Date Model Inventory) based on events.
   1. create component
   2. interface definition/agreement with community
   3. listen/filter to event 
   4. handle add event
   5. handle remote event
2. Pass through read and write data from application to node via ncmp using SDNC
3. Sync network model and data from node to cps via ncmp
4. Read cached data model or data from cps  to application via ncmp

Impacts

...

1. create rest interface on northbound for GET/POST/PUT/DELETE to access yang data.
2. create dmi-manager. Dmi responsibilities are
   1.  Create all interfaces/contract needed for DMI implentations 
   2.  Dmi manager is to select the dmi instance at runtime for cm handler.
   3.  At first, on change event, create mapping for cm-handler and dmi instance and sync yang model and data.
      
   4.  Filter only yang model/data xnf instances's cm-handle and store that.
3. create dmi instance for onap. For production its responsibility of admin to provide instance of dmi. This story is mainly for testing purpose.
   1. dmi instance (onap-dmi) have sdnc connector to access sdnc.
   2. call get/post/put/delete towards restconf interface
4. enhance ncmp-cps interface (need to identifiy).
   

...

1. create yang model for cm-handle and dmi instance identifier mapping.
   1. create api needed to access crud operations.

...

...

API Changes

To support the added functionality in NCMP, changes are expected in the CPS external interface CPS-E-05. (For overview of CPS interfaces, see the CPS architecture page.) Changes are planned in the following areas, matching items in the scope/priority table above:

• New APIs for reading data for CM handle
• New APIs for writing data for CM handle
• New API to request data sync for CM handle
• New API to retrieve model information for CM handle
• (stretch goal) New API to retrieve list of CM handles supporting a given module

Some existing CPS-E-05 APIs may be removed or deprecated if not currently used. See Decision #7

In addition to external APIs, extensions may be made to the CPS Core library to support some NCMP use cases. Plugin APIs will also be added to support communication between NCMP and DMI plugins.

Excerpt from CPS-391Spike: Define and Agree NCMP REST Interface :

Epics Summary

Jira filter all user stories in all epics:  

...

Head Tpic:

...

Component description diagram

Data Stores

     +-------------+                 +-----------+
     | <candidate> |                 | <startup> |
     |  (ct, rw)   |<---+       +--->| (ct, rw)  |
     +-------------+    |       |    +-----------+
            |           |       |           |
            |         +-----------+         |
            +-------->| <running> |<--------+
                      | (ct, rw)  |
                      +-----------+
                            |
                            |        // configuration transformations,
                            |        // e.g., removal of nodes marked as
                            |        // "inactive", expansion of
                            |        // templates
                            v
                      +------------+
                      | <intended> | // subject to validation
                      | (ct, ro)   |
                      +------------+
                            |        // changes applied, subject to
                            |        // local factors, e.g., missing
                            |        // resources, delays
                            |
       dynamic              |   +-------- learned configuration
       configuration        |   +-------- system configuration
       datastores -----+    |   +-------- default configuration
                       |    |   |
                       v    v   v
                    +---------------+
                    | <operational> | <-- system state
                    | (ct + cf, ro) |
                    +---------------+

     ct = config true; cf = config false
     rw = read-write; ro = read-only
     boxes denote named datastores

content=all

content=config

content=all

content=config

Component description diagram

Interfaces

Sequence diagrams

Image Removed