Note | ||
---|---|---|
| ||
Under construction |
- 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
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Guiding Principles
- NCM REST Interface will follow/be inspired by RESTConf interface for easy acceptance of and transition to this interface
- Interface will include concept of data-stores inspired by Network Management Datastore Architecture (NMDA) and as used in RESTConf
- Application should be abel to easily switch between 'pass-through' and other datastores (aslmo identical rest endpoint and responses)
Open Issues & Decisions
Description | Notes | Decision | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
1 | Priority of async calls | In Istanbul, async calls are required only in pass-through cases. NCMP does not have to handle these requests | |||||||||
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. | we should mainly support yang-data/json the default option for NCMP should be yang but we want to support both options - yang and the data node wrapper for pass through - yang data operational - data node | ||||||||
3 | In the URI will we distinguish between data and operations (RFC calls) as part of the path? | e.g. http://localhost:8080/ncmp/api/v1/data http://localhost:8080/ncmp/api/v1/operation | This only applies to pass-through yes, we will distinguish between data and operation | ||||||||
4 | Which query parameters will NCMP support? | 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 | We will use a dash for param names e.g. cm-handle (although it has since bene agreed we use 'ch' in this particular case) | |||||||||
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> | Optionally insert the resource path ('rp:') if it clashes with the current | ||||||||
8 | Granularity of update scenarios (and priority) |
| Priority is pass-through only so it depsn on teh RETSCOnf protocol what is supported. In jakarta or if required by other projects more fine grained 'operation' datsstore update options can be implemented | ||||||||
9 | There is no automatic fallback option for datastore in I | In a future releasereleases, we hope to have the automatic fallback option | The client will have the specify the datastore | ||||||||
10 | fields is a rest conf option, investigate is it fully supported by onap | Supported in pass through and the for ONAP DMI plugin but depending on the support by the actual target. The intention is to increase support 'fields' in future requirements in RFCfollowing RFC-8040 for operational datastore etc. | |||||||||
11 | Agree on URI syntax | Proposed syntax by CPS team <OP>/ncmp/<v{v-number}>/ch/<cm-handle>/<data|operations|{ncmp-operation}>/ds/{datastore}/[rp:]{resource-path}?{query} | review completed and proposed URI agreed |
RESTCONF/NETCONF relationship
...