...
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 (json) | ||||||||
| 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 | Legacy and new API docuemtnation needs to include output examples. Task created, see
| |||||||||
| 6 | camel case or dash in URI | We will use a dash for param names e.g. cm-handle (although it has since been 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}>/ch/<cm-handle>/<data|operations|{ncmp-operation}>/ds/{datastore}/[rp:]{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 depends on the RETSConf protocol that is supported. In Jakarta or if required by other projects more fine-grained 'operation' datastore update options can be implemented | ||||||||
| 9 | There is no automatic fallbackFallback option for datastore in release I | In future releases, we hope to have the automatic fallback option | The client will have the specify the datastoreYes, Istanbul will choose datastore based on presence of data (assuming model is always there) | ||||||||
| 10 | fields is a rest conf option, investigate is it fully supported by onap | Supported in pass-through for ONAP DMI plugin but depending on the support by the actual target. The intention is to increase support 'fields' in future requirements following 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 | ||||||||
| 12 | Will we combine query capabilities with update capabilities? | We have decided not to combine query capabilities with update capabilities | |||||||||
| 13 | Description of header limitations | HTTP Header Limitations LIMITATION NOTE: server implementations put size limits on the headers meaning header contents should be designed carefully : | |||||||||
| 14 | Will NCMP support paths for pass-through:running | The plugin will not do transformation or validation of paths in the case of pass-through:running | |||||||||
| 15 | Specification of path per cm handle | DMI Plugin can take cps paths or resconf paths and it needs to specify that per cm handle when cm handle is created | |||||||||
| 16 | What is the default path for NCMP | In NCMP default will always be cps path and depending on the adapter we can change it as needed per cm handle | |||||||||
| 17 | Fields parameter for datastore:operational? | The fields parameter is ignored in datastore:operational | |||||||||
| 18 | Is specifying the datastore mandatory? | Datastore is optional depending on the data being persisted or not | |||||||||
| 19 | Can the user request config=false data with ds:'ncmp-datastores:operational' if so what should NCMP do | ignore throw exception? | |||||||||
| 20 | Combining RESTConf without explicit pass-through, possibly not allowed? | Suggestion: only accept RESTConf paths with explicit passthrough-running | |||||||||
| 21 | DMI plugin is a part of cm handle registration. The rest endpoint on NCMP can be multiple calls | ||||||||||
| 22 | Retrieve a list of module names for cm handle - this will be used by ncmp to get the models. - assuming ncmp model discovery is complete and it is stored in cps core, this will come from cached information | ||||||||||
| 23 | Where will sync be implemented? | Implement sync in the dmi plugin and then have ncmp be able to pass on the request. This is not a bulk operation |
RESTCONF/NETCONF relationship
...
| # | 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 | passthrough-running | RESTConf Path only | N/A | N/A | N/A | > Istanbul |
| 12 | Bulk | ncmp-datastores:running | CPSPath only | N/A | N/A | N/A | > Istanbul |
| 13 | Action | passthrough-running | RESTConf Path only | N/A | N/A | N/A | Istanbul? |
| 14 | Action | ncmp-datastores:running | CPSPath only | N/A | N/A | N/A | Istanbul? |
Outline of decisions and use cases for Istanbul
Datastore, paths and format combinations
| # | User DS Choice | Data Synced in CPS-Core* | Expected path-format | accept-header | Required Transformations | Data Source | 'config' | Notes | Priority |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Not Specified | Yes | cpsPath | application/yang-data+json | input: none output: json to yang-data+json | CPS-Core | true | NCMP needs to remove DataNode wrapping | |
| 2 | Not Specified | Yes | cpsPath | application/json | input:none output:none | CPS-Core | true | ||
| 3 | Not Specified | No | cpsPath | application/yang-data+json | input: ONAP DMI-Plugin converts cpsPath to RESTConf Path | xNF | true false | NCMP can provide a helper method for transformation of path | 2 |
| 4 | Not Specified | No | cpsPath | application/json | N/A | N/A | N/A | NOT Supported (there are NO DataNode objects in CPS to output as JSON) | |
| 5** | Not Specified | No | RESTConf | application/yang-data+json | input:none output:none | xNF | true false | ||
| 6** | Not Specified | No | RESTConf | application/json | NA | NA | N/A | NOT Supported (there are NO DataNode objects in CPS to output as JSON) | |
| 7 | ncmp-datastores:passthrough-running | N/A | RESTConf | application/yang-data+json | input:none output:none | xNF | true false | 1 | |
| 8 | ncmp-datastores:passthrough-running | N/A | RESTConf | application/json | NA | N/A | N/A | NOT Supported (there are NO DataNode objects in CPS to output as JSON) | |
| 9 | ncmp-datastores:passthrough-running | N/A | cpsPath | N/A | NA | N/A | NA | NOT Supported | |
| 10 | ncmp-datastores:operational | Yes | cpsPath | application/yang-data+json | input: none output: json to yang-data+json | CPS-Core | true | NCMP needs to remove DataNode wrapping | |
| 11 | ncmp-datastores:operational | Yes | cpsPath | application/json | input:none output:none | CPS-Core | true | ||
| 12** | ncmp-datastores:operational | Yes | RESTConf | N/A | N/A | N/A | N/A | NOT supported |
*Note: data not (never) synced but model IS present in CPS Core and associated with the cm-handle
...