Versions Compared

Key

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

Table of Contents

...

#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)


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

Drawio
bordertrue
diagramNameNCP DMI Plugin Options
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1021
revision4

...

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.

...