Page Comparison

Table of Contents

Jira Legacy

server	System Jira
serverId	4733707d-2057-3a0f-ae5e-4fd8aff50176
key	CPS-736

Issues & Decisions

#

Issue

Notes

Decision

1

Separating of Interfaces

Tony recommended NOT to split the interfaces.

No need in ONAP
Cost of this user story would double-triple
Specialized plugin can throw 'not support' exceptions on unimplemented methods

Check with stakeholders (Peter and Kieran)

The decision made is: NOT to separate interfaces

Description

Currently it is only possible to register a single dmi-plugin service name with NCMP.

...

These changes must be backward compatible with the existing Istanbul release where the dmi-plugin is a single service managing both model and data requests.

Register 2 separate plugins for different responsibilities model v. data (for scaling purposes)

Backward compatible! ie can stil register 1 plugin for both (ONAP plugin will keep using that)

Basic checks while registering: Either 2 separate Plugins OR 1 common plugin for both responsibilities. If not reject registration!

Required DB Schema update, see https://lf-onap.atlassian.net/wiki/display/DW/CPS-352+%3A+Create+yang-model+for+DMI-registry+data (new revision of that model) Possible add 2 new leaves for separate registration

Proposal Diagram

Drawio

border	true

diagramName	NCP DMI Plugin Options
simpleViewer	false
width
links	auto
tbstyle	top
lbox	true
diagramWidth	1021
revision	14

To realize this request the cmhandle registration (as well as update and delete when implemented in Jakarta) interfaces need updates to support a dmiDataPlugin and a dmiModelPlugin definition.

At least one of either (dmiPlugin) or (dmiDataPlugin + dmiModelPlugin) must be defined in the interface. Otherwise a "Bad Request" error will be returned to calling dmi-plugin.

Interface Sketch

DMI notifies NCMP of new , deleted or changed cmhandles DMI Plugin NCMP. Including initial registration

POST{ncmpRoot}/ncmp/v1/ch/

Scenario : DMI notifies NCMP of new cmhandles
Method : POST
URI : {ncmpRoot}/ncmp/v1/ch/
Header :
    Content-Type: application/json

Request Body

Request Body : {
      "dmiDataPlugin" : "onap.dmi.data-plugin",       "dmiModelPlugin" : "onap.dmi.model-plugin",
      "createdCmHandles" : [ {   "cmHandle" : "rf4er5454",
                                 "cmHandleProperties" :
                                   { "subSystemId" : "system-001" }
                             }, {..} ],
      "updatedCmHandles" : [ .. ],
      "removedCmHandles" : [ "node-1", "node-2" , ... ]
  }

json attributes:

"dmiDataPlugin"/"dmiModel" are resolvable service names
"createdCmHandles" used for initial cm handle registrations or subsequent
cmhandle creations
"updatedCmHandles"
Used for updates to cmhandles. Same structure as for create handles
"removedCmHandles" array of cmhandles that have been deleted

openAPI Updates

To support this the equivalent openAPI will be similar to the below in bold.

RestCmHandle:

required:

...

RestDmiPluginRegistration:
type: object
properties:
dmiPlugin:
type: string
required: false
example: onap-dmi-plugin
dmiDataPlugin:
type: string
required: false
example: onap-dmi-data-plugin
dmiModelPlugin:
type: string
required: false
example: onap-dmi-model-plugin
createdCmHandles:
type: array
items:
$ref: '#/components/schemas/RestCmHandle'
updatedCmHandles:
type: array
items:
$ref: '#/components/schemas/RestCmHandle'
removedCmHandles:
type: array
items:
type: string

NCMP-DMI APIs (Data/Model)


/v1/ch/{cmHandle}/modules
/v1/inventory/cmHandles
/v1/ch/{cmHandle}/moduleResources
/v1/ch/{cmHandle}/data/ds/ncmp-datastore:passthrough-operational
/v1/ch/{cmHandle}/data/ds/ncmp-datastore:passthrough-running

Versions Compared

Old Version 4

New Version Current

Key