CPS-736 Allow separate registration of DMIDataPlugin and DmiModelPugin

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)

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.

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