Versions Compared

Key

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

Table of Contents

...


IssueNotesDecision
1How will hostname and port be provided when dmiPlugin 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. "dmiPlugin" : { <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.dmiPlugin"
2Additional information in request body duplicates cmHandleId this is redundant informationSuggested to remove from request body to avoid possible error scenarios.Only the one with the additionalInformation is needed and remove body
3No need for Sync method, this is basic standard read operation at the root level for that cmHandle

4Use include 'location' property when request yang-module sourcesSuggestion: do include it in the request but allow dmiPlugin 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.

Location is not needed for any plugin and could only lead to ambiguity therefore will NOT be included in this request

DMI URI

DMI URI format to follow below pattern Sandeep Shah

<OP>dmi/<vBelow table shows the proposed interface, actual implementation might deviate from this but can be accessed from

DMI URI format to follow below pattern

<OP>dmi/<v{vNumber}>/ch/<cmHandle>/<data|operations|dmiAction>/ds/<datastore>/[rp:]<resourcePath>?<query>

...

Code Block
languagexml
titlerequest body
{
  “operation”: “<operation>”,         // Valid operations are: “create”, “read”, “update” and “delete”.
                                      // For update, replace and patch is distinguished by the HTTP method (PUT or PATCH).
  "dataType": "<dataType>",

    “data”: {                           // Embedded data as a String.
    <data>                            // required for create and update operations. Optional filter-data for read-operations
  },

  “cmHandleProperties”: {           // Additional properties for CM handle previously added by DMI plugin and stored in NCMP.
    <properties>
  }
}


{dmiRoot}/dmi/v1/ch/<cmhandle>/data/ds/ncmp-

Below table shows the proposed interface, actual implementation might deviate from this but can be accessed from

Expand
titleAPI details
UsecaseREST MethodURI1Add a data resource for a cmHandlePOST

UsecaseREST MethodURI
1Add a data resource for a cmHandlePOST

{dmiRoot}/dmi/v1/ch/<cmhandle>/data/ds/ncmp-datastore:running/{parentDataResourceIdentifier}

{
<new-yang-data-resource>
}

Content-Type: application/json

"data" payload : yang-data+json

2Delete a data resource for a cmHandlePUT{dmiRoot}/dmi/v1/ch/<cmHandle>/data/ds/ncmp-datastore:running/{resourceIdentifier}
3Patch a data resource for a cmHandlePATCH

{dmiRoot}/dmi/v1/ch/<cmHandle>/data/ds/ncmp-datastore:running/{resourceIdentifier}

{
<yang-data-for-merging>
}

Content-Type: application/json

"data" payload : yang-data+json

4Patch multiple child resources for a single cmHandlePATCH

{dmiRoot}/dmi/v1/ch/<cmHandle>/data/ds/<dsName>/{resourceIdentifier}


Content-Type: application/json

"data" payload : yang-patch+json

5Execute a yang action on a cmhandle instancePOST

{dmiRoot}/dmi/v1/ch/<cmHandle>/data/ds/ncmp-datastore:operational/{resourceIdentifier}/{action}


input: {
         "param1Name" :"param1Value”,
          "param2Name" : "param2Value”

}


Note : If the "action" statement has no "input" section, the request message MUST NOT include a message-body

6Execute an rpc operationPOST

{dmiRoot}/dmi/v1/operations/ch/<cmHandle>/ds/ncmp-datastore:operational/ {module-name}:{action}

{ input: {
            "param1Name" : "param1Value”,
             "param2Name" : "param2Value”
} }

Note: If there is no "input" section, the request MUST NOT include a message-body

7Read a filtered set of data under a data resource for a cmHandlePUT

{dmiroot}/dmi/v1/ch/<cmHandle>/data/ds/ncmp-datastore:operational/{resourceIdentifier}?fields={fields-expression}

OptionDescription
fieldsRequest a subset of the target
resource contents


8Read data resources with specified fields under a given data resource for a given cmHandlePUT

{dmiRoot}/dmi/v1/ch/<cmHandle>/data/ds/ncmp-datastore:operational/{resourceIdentifier}?fields={fields-expression}


OptionDescription
fieldsRequest a subset of the target
resource contents


9Get data resource with 'fileds' for a cmhandle with a given scope conditionPUT{dmiRoot}/dmi/v1/ch/{cmHandle}/data/ds/ncmp-datastore:operational/{resourcepath}?fields={fields}&scope={scope}
10Read descendant nodes to a given depth for a given cmHandlePUT

{dmiRoot}/dmi/v1/ch/{cmHandle}/data/ds/ncmp-datastore:operational/{resourceIdentifier}?depth={level}


OptionDescription
depthRequest limited sub-tree depth in
the reply content
If '1' then only immediate resource
is retrieved
If '2' then resource plus next level
resources are retrieved


11Replace data for a CMHandlePUT

{dmiRoot}/dmi/v1/ch/<cmHandle>/data/ds/ncmp-datastore:running/{resourceIdentifier}

{data : {

            .... the complete tree config to be replaced

      }}


...

View file
nameDMI NCMP Model Sync.pptx
height150
 This presentation illustrates the API methods #1, #3 and #4 detailed below


Expand
titleAPI Details

Below table shows the proposed interface, actual implementation might deviate from this but can be accessed from

*For response output, where applicable the yang-library format and conventions are used 'as is'  or extended

#Use CaseRest MethodURIExample*
1

Get module set for a cmhandle


POST{dmiRoot}/dmi/v1/ch/cmhandle-001/modules

Header :
Content-Type: application/json


Code Block
languagexml
titleRequest Body
{
  "operation": "read",
    "cmHandleProperties ": {
      "subSystemId": "system-001"
    }
  }
}

Code Block
languagexml
titleResponse Body
Response:  
     "schemas": [
                    {
                      "moduleName": "example-identifier",
                      "revision": "example-version",
                      "namespace": "example-namespace"
                    },
					{
						...
					}
                  ]
                }

2Get yang module source for a list of modulesPOST

{dmiRoot}/dmi/v1/ch/<cmHandle>/moduleResources


DMI Plugin will make multiple requests to xNF and combine the result in a list


Code Block
languagexml
titleRequest Body
{
  "operation": "read",
	"dataType": "application/json",
    "data": {
       "modules": [
        {
          "name": "pnf-sw-upgrade",
          "revision": "2019-12-03"
        }
      ]
    },
    "cmHandleProperties": {
      "subSystemId": "system-001"
    }
}


Response: a list yang module references and source for each

Code Block
languagexml
titleResponse Body
[ {
"name" : "pnf-sw-upgrade",
"revision" : "2019-12-03",
"yang-source": "some-source", {...} ]


...