...
| Issue | Notes | Decision |
|---|
| 1 | How will hostname and port be provided when DMI-Plugin register itself and its list of cmHandles with NCMP | The team thinks that the information should instead be provided in the form of a ‘host-name’ and a ‘port’ (there was some debate on service-name v. host-name but it was settled on host-name)
e.g. "dmi-plugin" : { <host-name>, <port> }
Where the host-name is unique. (the DB might assign an internal unique ID for each entry but that is just for indexing and x-referencing in a relation DB and this ID is not to be used/ exposed externally) | Instead of using ‘host-names’ and ‘ports’ parameters between java applications when in the cloud all we need is ‘service-names’ . The mapping of service-names to hosts and ports is done as part of the cloud configuration, in our case Kubernetes. And these are dynamic! The client application can then use a simple dns-lookup to connect to an instance of the service. Using service names also allows any plugin to use implement scaling as they see fit e.g. partitioning
For the ONAP DMI Plugin which initial have only 1 instance we can simply hard-code the service-name and us the same name in the Kubernetes configuration e.g. “onap.cps.dmi-plugin" |
| 2 | Additional information in request body duplicates cmHandleId this is redundant information | Suggested to remove from request body to avoid possible error scenarios. | Only the one with the additionalInformation is needed and remove body |
| 3 | No need for Sync method, this is basic a standard read operation at root level for that cm-handle |
|
|
| 4 | Use include 'location' property when request yang-module sources | Suggestion: do include it in the request but allow DMI-Plugin to decide to use it or now | Location (this leaf is called schema in older RFC7895) is not mandatory to support in YANG library and nodes may not include it. Another alternative presumably used also by ODL itself is the <get-schema> RPC. The key difference is that the YANG module definition is sent directly over the NETCONF channel, not requiring separate file servers and clients. So this is maybe one more reason that the ONAP DMI plugin currently doesn’t need the location attribute. |
| 5 | Get ModuleSet The request body should contain a list of model references instead of cm-handles with additional info
| Possible flow: - Recover all cmhandles
- NCMP asks each cmhandle for thie modules etc (the request below)
- NCMP uses the “location” to get the missing modules
|
|
DMI URI
DMI URI format to follow below pattern Sandeep Shah
...
| Expand |
|---|
|
| # | Use Case | Rest Method | Service | URI | Example |
|---|
| 1 | DMI notifies NCMP of new , deleted or changed cmhandles DMI Plugin NCMP. Including initial registration | POST json attributes: - "dmi-plugin" resolvable servicename
- "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
from the network (no additional properties
| NCMP | {ncmp-root}/ncmp/v1/ch/ | Scenario : DMI notifies NCMP of new cmhandles
Method : POST
URI : {ncmp-root}/ncmp/v1/ch/
Header :
Content-Type: application/json
Request Body : {
"dmi-plugin" : "onap.dmi.plugin",
"createdcmhandles" : [ { "cmhandle" : "rf4er5454",
"additionalProperties" :
{ "subsystemId" : "system-001" }
}, {..} ],
"updatedcmhandles" : [ .. ],
"removedcmhandles" : [ "node-1", "node-2" , ... ]
} | | 2 | Get all the registered cmhandles for a given plugin | GET | NCMP | {ncmp-root}/ncmp/v1/dmi-plugins/{plugin-id}/ch | Scenario : Get all cmhandles from NCMP for a given dmi-plugin. May be used
for conciliation
Method : GET
URI : {ncmp-root}/ncmp/v1/dmi-plugins/{dmi-plugin}/ch
Header :
Content-Type: application/json
Success Response :
HTTP/1.1 200 Ok
Date: Thu, 26 Jan 2021 20:56:30 GMT
Server: example-server
{ "cmhandles" : [ {
"cmhandle" : "node-1",
"additionalProperties" : [ "subSystem" : "system-001" ]
} ]
} | | 3 | Get module set for a cmhandle
| PUT | DMI-Plugin | {dmi-root}/dmi/v1/ch/cmhandle-001/module-sets | Header :
Content-Type: application/json
Body :
{ "operation" : "read",
"cmhandle" : "cmhandle-001",
"additionalProperties" : ["subSystem" : "subsystem-001"]}
Response:
{
"ietf-yang-library:yang-library" : [
{ "module-set" : [ {
"name" : "sample-module",
"module" : [
{
"name" : "_3gpp-nr-nrm-nrsectorcarrier",
"revision" : "2020-12-09",
"namespace" : "urn:3gpp:sa5:_3gpp-nr-nrm-nrnetwork-nrsectorcarrier",
}
...
}
| | 4 | Get yang module for a list of modules | POST | DMI-Plugin | {dmi-root}/dmi/v1/model/ch/<cmhandle>
*Include 'location' attribute in request so DMI PLugin can use it if needed, see open issue #4 | Body :
{ "operation" : "read",
"cmhandle" : "cmhandle-001",
"additionalProperties" : ["subSystem" : "subsystem-001"]
"modules" : [ "org:onap:cps:test:store:2020-12-09??", "org:onap:cps:test:store" ] }
Response : a list yang module sources
{
"org:onap:cps:test:store" : [
{
"module" : [ {
"name" : "books",
"module" : [
{
"name" : "books",
"revision" : "2020-12-09",
"namespace" : "org:onap:cps:test:bookstore",
"module-content" : "paper back",
"submodule" : [
{
"name" : "Fiction",
"revision" : "2020-12-17",
"namespace" : "org:onap:cps:test:fiction",
]
....
} | | 5 | Sync data to ncmp - NCMP requests sync of cmhandle yang data tree |
|
| Not separate URI required, this is equivalent to a read request at root level see #7 in previous table. See open issue #3 |
|
|
...
