CPS-736 Allow separate registration of DMIDataPlugin and DmiModelPugin

CPS-736 - Getting issue details... STATUS

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.

It is desirable to be able to provide the ability to register separate dmi-plugin services for data and models dmi-plugin services.

NCMP will then direct the cm data requests to the data dmi-plugin service while model related requests will be directed to the model dmi-plugin service.

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://wiki.onap.org/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

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

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:

- cmHandle

type: object

properties:

cmHandle:

type: string

example: cmHandle123

cmHandleProperties:

$ref: '#/components/schemas/RestCmHandleAdditionalProperties'

RestCmHandleAdditionalProperties:

type: object

additionalProperties:

type: string

example: system-001

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

Space shortcuts

Page tree