CPS-736 Allow separate registration of DMIDataPlugin and DmiModelPugin

Owned by Toine Siebelink
Last updated: Oct 26, 2021 by Joseph Keenan
2 min read


CPS-736 - Getting issue details... STATUS

Issues & Decisions

#IssueNotesDecision
1Separating of InterfacesTony 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://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


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)


#APIData/ModelNotes
1
/v1/ch/{cmHandle}/modules
Model
2
/v1/inventory/cmHandles
ModelSome ambiguity for this API but it was decided it belongs with model
3
/v1/ch/{cmHandle}/moduleResources
Model
4
/v1/ch/{cmHandle}/data/ds/ncmp-datastore:passthrough-operational
Data
5
/v1/ch/{cmHandle}/data/ds/ncmp-datastore:passthrough-running
Data