Versions Compared

Old Version 4

changes.mady.by.user Toine Siebelink

Saved on

compared with

New Version Current

changes.mady.by.user Joseph Keenan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents


Jira
serverONAP Jira
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyCPS-736

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.

...

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

draw.io Diagram
bordertrue
diagramNameNCP DMI Plugin Options
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1021
revision14


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)


#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