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.
...
| 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 BodyRequest 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.
...