Table of Contents

References

...

RESTful API Design Specification

Issues and Decisions

#	Issue	Notes	Decision
1	How 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"
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 standard read operation at the root level for that cmHandle
4	Use include 'location' property when request yang-module sources	Suggestion: 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

...

5

Inconsistent use of "Operation" and/or HTTP Methods to distinguish write operations

Currently this page proposes to use "Operation=update" request body parameter for restconf "Replace" and "Patch" operations and use the HTTP (RESTFul) operation to distinguish between them. It also proposes to use PUT HTTP for Read and Delete operations

Basically a very confusing an unintuitive use of HTTP operations to distinguish ambiguous operations that instead easily could be defined by just using the 'operation' field in the request body.

Proposal Toine: For Consistent (restful) design I would suggest to think as the operation to DMI-Plugin (always with body) as "creating a new order to do something" toward DMI-Plugin. Ie always a HTTP POST (or PUT?) operation. The "operation " in the body can simple be extended to include both "update" and "patch" as required. If the 'operation' is NOT supplied "read" wil be assumed as the default operation

Proposal agreed by stakeholders in meeting 09 Nov 2021

Only 'POST' method needs to be supported
use term 'Update' instead of 'replace'

DMI URI

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

Gerrit Source
Read-the-docs: https://docs.onap.org/projects/onap-cps-ncmp-dmi-plugin/en/latest/design.html

DMI URI format to follow below pattern

URI	Mandatory or Optional	Description
<OP>	mandatory	the HTTP method
dmi	mandatory	the dmi root resource
<v{vNumber}>	mandatory	version of the dmi interface is the target resource URI is the query parameter list
<cmHandle>	mandatory	unique (string) identifier of a yang tree instance.
<data\|operations\|dmiAction>	mandatory	yang data, rpc operation or a (non-modeled) dmi action
{datastore}	mandatory	mandatory datastore
<resourcePath>	optional	the path expression identifying the resource that is being accessed by the operation. If this field is not present, then the target resource is the API itself.
<query>	optional	the set of parameters associated with the RESTCONF message; see Section 3.4 of [RFC3986]. RESTCONF parameters have the familiar form of "name=value" pairs. Most query parameters are optional to implement by the server and optional to use by the client. Each optional query parameter is identified by a URIURI

NCPS-NCMP - DMI Plugin Write Request Flow

See CPS-NCMP - DMI - SDNC Request and Response Mapping

Datastore

If the cmhandle metadata indicates that data is not synched in CPS then the request is forwarded to the dmiPlugin

...

The URI prefix is /dmi instead of /ncmp.
For non-passthrough datastores, the resource path will be converted from cpsPath to RESTConfPath
The body for each request will contain additional information and any data provided on the NCMP interface (write operations) will be embedded in a larger JSON structure as described in example below.
Since all requests will have a message body, in some cases the HTTP method will be different to allow passing data. Thus PUT is used instead of GET and DELETE.POST can be used, the actual operation will be read from the body.

Excerpt

Request Format for Data Access

Code Block

language	xml
title	request body

{
  “operation”: “<operation>”,         // Valid operations are: “create”, “read”, “update”, “patch” and “delete”.

// For update


  "dataType": "<dataType>",

replace

and

patch

is

distinguished

by

the

HTTP

method

(PUT

or PATCH). "dataType": "<dataType>",

// e.g. "application/yang.data"

    “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> } }

Expand

title	API details

operations
  },

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

Expand

title	API details

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

Gerrit Source
Read-the-docs: https://docs.onap.org/projects/onap-cps-ncmp-dmi-plugin/en/latest/design.html

Usecase

REST Method

URI

1

Add a data resource for a cmHandle

POST

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

{
<new-yang-data-resource>
}

Content-Type: application/json

"data" payload : yang-data+json

2

Delete a data resource for a cmHandle

PUT

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

3

Patch a data resource for a cmHandle

PATCH

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

{
<yang-data-for-merging>
}

Content-Type: application/json

"data" payload : yang-data+json

4

Patch multiple child resources for a single cmHandle

PATCH

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

Content-Type: application/json

"data" payload : yang-patch+json

5

Execute a yang action on a cmhandle instance

POST

{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

6

Execute an rpc operation

POST

{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

7

Read a filtered set of data under a data resource for a cmHandle

PUT

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

Option	Description
fields	Request a subset of the target resource contents

8

Read data resources with specified fields under a given data resource for a given cmHandle

PUT

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

Option	Description
fields	Request a subset of the target resource contents

9

Get data resource with 'fileds' for a cmhandle with a given scope condition

PUT

{dmiRoot}/dmi/v1/ch/{cmHandle}/data/ds/ncmp-datastore:operational/{resourcepath}?fields={fields}&scope={scope}

10

Read descendant nodes to a given depth for a given cmHandle

PUT

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

Option	Description
depth	Request 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

11

Replace data for a CMHandle

PUT

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

{data : {

.... the complete tree config to be replaced

}}

...

View file

name	DMI NCMP Model Sync.pptx
height	150

This presentation illustrates the API methods #1, #3 and #4 detailed below

...


height	150

This presentation illustrates the API methods #1, #3 and #4 detailed below

Expand

title	API Details

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

Gerrit Source
Read-the-docs: https://docs.onap.org/projects/onap-cps-ncmp-dmi-plugin/en/latest/design.html

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

#

Use Case

Rest Method

URI

Example*

1

Get module set for a cmhandle

POST

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

Header :
Content-Type: application/json

Code Block

language	xml
title	Request Body

{
  "operation": "read",
    "cmHandleProperties ": {
      "subSystemId": "system-001"
    }
  }
}

Code Block

language	xml
title	Response Body

Response:  
     "schemas": [
                    {
                      "moduleName": "example-identifier",
                      "revision": "example-version",
                      "namespace": "example-namespace"
                    },
					{
						...
					}
                  ]
                }

2

Get yang module source for a list of modules

POST

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

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

Code Block

language	xml
title	Request 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

language	xml
title	Response Body

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

...

Versions Compared

Old Version 78

New Version Current

Key

References

Issues and Decisions

DMI URI

DMI URI

NCPS-NCMP - DMI Plugin Write Request Flow

Datastore

Request Format for Data Access

Page Comparison

Versions Compared

Old Version 78

New Version Current

Key

References

Issues and Decisions

DMI URI

DMI URI

NCPS-NCMP - DMI Plugin Write Request Flow

Datastore

Request Format for Data Access