...
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 controlled by "accept-header" | ||||||||
| 3 | In the URI will we distinguish between data and operations (RFC calls) as part of the path? | e.g. http://localhost:8080/ncmp/v1/data http://localhost:8080/ncmp/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 documentation 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 | Fallback option for datastore in release I | Yes, 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 ncmp/operational? | The fields parameter is ignored in ncmp/operational (in istanbul release) | |||||||||
| 18 | Is specifying the datastore mandatory? | Datastore is | optional depending on the data being persisted or notmandatory in Istanbul release | ||||||||
| 19 | Register a DMI plugin with NCMP | DMI plugin is a part of cm handle registration. The rest endpoint on NCMP can be multiple calls | |||||||||
| 20 | Retrieve list of modules (names) for a cmHandle | 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 | |||||||||
| 21 | 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 | |||||||||
| 22 | Config-true only support (filter out config-false data) | Currently 'ncmp-datastores:operational' will include (and return) config-false data | Future release could support additional flag or a ' ncmp-datastores:running' to filter out config-false data | ||||||||
| 23 | Enable NCMP to convert cpsPath to mutliple options(RESTConf, netConf, leave as cpsPath) | When other DMI-Plugins are realized they might need a different conversion then the default from cspPath to RESTConf. This could be configured by using a known property for each cm-handle | No required in Istanbul. But DB model can easily be updated to cater for this when needed | ||||||||
| 24 | Datastore conversion in NCMP or DMI-Plugin | DMI-Plugin will know best how to convert. This will also reduce future impacts on NCMP for new options. | |||||||||
| 25 | What datastore/s (name/s) is/are supported by NCMP to referred to the cached data. 'Operational' or 'running' | 'operational' would imply RO and config=false data is included. 'To also support 'running' using the same data a filter would have to be applied | ncmp-datastore:operational wil be used for the data in the cache which wil include config + non-config data | ||||||||
| 26 | Consider fallback option when user specifies ncmp/operational but dat is NOT synced | Yes will be supportedNCMP will forward requests for un-synced cmHandles to the DMI Plugin (Including required transformation of resource path etc.) |
RESTCONF/NETCONF relationship
...
| 1 | ncmp-datastores:operational (RO / config=true/false) | Read from the CPS "operational" store (cached) | config true and config false data |
| 2 | ncmp-datastores:passthrough-running (RW / config=true)* | Read/Write to/from the live devices ietf-datastores:running (no local ncmp validation) | config-true data only |
| 3 | ncmp-datastores:passthrough-operational (RO / config=true/false)* | config true and config false data |
...
| 4 | ncmp-datastores:running (RW / config=true/false) |
Future datastores to be supported by NCMP might include :
| 1 | ncmp-datastores:running (RW / config=true/false) | Read/Write to the CPS "intended" store (with validation). | config-true data only, see decision #23 | passthrough-intented (RO) | Read from the live | 2 | ncmp-datastores:passthrough-intented (RO) | Read from the live devices ietf-datastores:intended | ? | 3 | ncmp-datastores:passthrough-operational (RO)Read from the live devices ietf-datastores:operational | config true and config false data |
If datastore (ds/{datastore}) is omitted from URI, the datastore from cmhandle is used
...
| Excerpt | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Datastore, paths and format combinations
*'Operation;' or 'running' see open issue #25 Works Items for above.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
...