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