- Get the latest study information from Kieran Mccarthy <kieran.a.mccarthy@ericsson.com>
- Create a Wiki page with a clear diagram showing NCM and DMI and its interfaces detailing the scope of THIS (and other) spike
- Update V1 of the interface (communicate with E2E Slicing)
- Detail CRUD operations
- Detail Patch
- Include datastore options (pass-through)
- Agree on parameter names and use them consistently
- Agree on JSON output format
- Resource 'path' can cover cps-paths, rest-conf path (for pass-through), and any proprietary paths
- Only 'hint' at
- async options
- bulk operations
A/C
- Wiki page detailing points above
- Share an agreement with the team
- Present at community
Out of scope
- actual YAML definitions (separate user story)
CPS-391 - Getting issue details... STATUS
Open Issues & Decisions
Description | Notes | Decision | |
|---|---|---|---|
| 1 | Priority of async calls | ||
| 2 | Will we use the data node wrapper on GET rest operations? | Currently, we wrap the response of GET operations using the data node wrapper. | |
| 3 | In the URI will we distinguish between data and operations (RFC calls) as part of the path? | e.g. http://localhost:8080/cps/api/v1/data http://localhost:8080/cps/api/v1/operation | |
| 4 | Parent data resource identifier can handle any path using the same query parameter
| ||
| 5 | Yml should include return types and examples of the payload | ||
| 6 | camel case or dash in URI | ||
| 7 | Insert /resource-path in front of the resource path to prevent ambiguous paths | <OP>/ncmp /<v{v-number}>/cmhandle/<cm-handle>/<data|operations|{ncmp-action}>/ds/{datastore}/resource-path/<resource-path>?<query> | |
| 8 | Granularity of update scenarios (and priority) |
|
Principles
- Follow principles/patterns of RESTCONF RFC-8040
- Follow principles/patterns of yang-patch RFC-8072
- Follow principles/patterns of RESTCONF NMDA RFC-8527
RESTCONF/NETCONF relationship
NCMP URI
NCMP URI format to follow below pattern
<OP>/ncmp /<v{v-number}>/cmhandle/<cm-handle>/<data|operations|{ncmp-action}>/ds/{datastore}/<resource-path>?<query>
| URI | Mandatory or Optional | |
|---|---|---|
| <OP> | the HTTP method | Mandatory |
| ncmp / | the ncmp root resource | Mandatory |
| <v{v-number}> | version of the ncmp interface <path> is the target resource URI <query> is the query parameter list | Mandatory |
| cm-handle /<cm-handle> | unique (string) identifier of a yang tree instance. | Optional |
| <data|operations|{ncmp-action}> | request category - yang data, rpc operation or a (non-modelled) ncmp api action | Mandatory |
| ds/{datastore} | optional datastore | Optional |
| <resource-path> | 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. | Optional |
| <query> | 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 URI | Optional |
Datastores
New datastores are defined for ncmp to access the CPS 'intended' or 'operational' datastore.
Alternatively, the request can be sent directly to the 'device' itself (bypassing CPS datastores) using one of the 'passthrough-*' datastores options as below
The new ncmp datastores required for ONAP Release I include :
| 1 | ncmp-datastores:running (RW) | Read/Write to the CPS "intended" store (with validation). Then do subsequent write on DMI interface with ds ietf-datastores:running. |
| 2 | ncmp-datastores:operational (RO) | Read from the CPS "operational" store. |
| 3 | ncmp-datastores:passthrough-running (RW) | Read/Write to/from the live devices ietf-datastores:running (no local ncmp validation) |
Future datastores to be supported by NCMP include :
| 1 | ncmp-datastores:passthrough-intented (RO) | Read from the live devices ietf-datastores:intended ncmp-datastores:passthrough-operational (RO) : Read from the live devices ietf-datastores:operational |
| 2 | ncmp-datastores:passthrough-candidate (RW) | Read from the live devices ietf-datastores:candidate |
If datastore (ds/{datastore}) is omitted from URI AND the model/moduleSet is not available in NCMP, the datastore defaults to ncmp-datastores: passthrough-running
If datastore (ds/{datastore}) is omitted from URI AND the model/moduleSet exists, the datastore defaults to ncmp-datastores:running
Yang data resource actions and RPC operations are run directly on the 'device' meaning ncmp-datastores:passthrough-running is used for these request
| # | Usecase | NCMP Datastore | Path | ?fields | ?topic | Query | Time frame |
|---|---|---|---|---|---|---|---|
| 1 | Read | passthrough-running | RESTConf Path only | Implemented by SDNC/Node | Implemented by DMI Plugin | Not supported | Istanbul |
| 2 | Read | ncmp-datastores:operational | CPSPath only | TBD | TBD | Limited xpath functionality | Istanbul |
| 3 | Create | passthrough-running | RESTConf Path only | N/A | N/A | N/A | Istanbul |
| 4 | Create | ncmp-datastores:running | CPSPath only | N/A | N/A | N/A | Istanbul |
| 5 | Delete | passthrough-running | RESTConf Path only | N/A | N/A | Not supported | Istanbul |
| 6 | Delete | ncmp-datastores:running | CPSPath only | N/A | N/A | Not supported | Istanbul |
| 7 | Update | passthrough-running | RESTConf Path only | N/A | N/A | N/A | Istanbul |
| 8 | Update | ncmp-datastores:running | CPSPath only | N/A | N/A | N/A | Istanbul |
| 9 | Patches | passthrough-running | RESTConf Path only | N/A | N/A | N/A | Istanbul |
| 10 | Patches | ncmp-datastores:running | CPSPath only | N/A | N/A | N/A | > Istanbul |
| 11 | Bulk | > Istanbul | |||||
| 12 | > Istanbul | ||||||
| 13 | Action | Istanbul? | |||||
| 14 | Istanbul? |
REST API
| Req/usecase | REST Method | URI / Payload | Header Parameters | Request/Response Example | Status | |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | ||||||
| 3 | ||||||
| 4 | ||||||
| 5 | ||||||
| 6 | ||||||
| 7 | ||||||
| 8 | ||||||
| 9 | ||||||
| 10 | ||||||
| 11 | ||||||
| 12 |
Output Specification
?fields={fields}&topic= {topicId}
Assynchronous
?fields={fields}&topic= {topicId}
Required Task
# | Description | Notes | Decision |
|---|---|---|---|
| 1 | Yml update with return types with examples of the payload | ||
| 2 | Update CPS openAPI.yml with return types | CPS-401 - Getting issue details... STATUS |