...
# | Issue | Notes | Decision | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Which operation(s) need support for multiple cm handles? |
if many what is the priority? | agreed with kieran mccarthy Only Get (read) (in future other operations might be support batch option too) | ||||||||
| 2 | Which datasources should be supported? | Do we need to support passthrough-only no-cached() data only ? | agreed with kieran mccarthy : all passthrough datastores will be supported Not implemented (yet) response, for other datastores | ||||||||
| 3 | URL pattern for NCMP bulk endpoints | Existing : /v1/ch/{cm-handle}/data/ds/{datastore-name} CPS Proposed : /v1/batch/data/ds/{datastore-name} ( include cm handles into payload / body and leave datastore into url) | agreed with kieran mccarthy : Follow the existing interfaces as much as possible for consistency and efficiency | ||||||||
| 4 | keep datastore, topic and optional parameters in the URL itself instead into body. | CPS prefers keep interface similar as single cm handle interface (consistency and cost) Existing : ...&topic=topicParamInQuery | agreed with kieran mccarthy : Follow the existing interfaces as much as possible for consistency and efficiency | ||||||||
| 5 | support in ONAP DMI-plugin | agreed with Toine Siebelink : ONAP plugin can respond with not implemented yet code, | |||||||||
| 6 | Response always Async ie. topic is compulsory ? | Assume topic is compulsory (defined in OPenApi) → Response therefore wil be 400 if not supplied | Agreed with kieran mccarthy : Topic is optional but system will respond with 'Not implemented (yet when not specified or blank | ||||||||
| 7 | Should NCMP Amalgamate Async responses from DMI-Plugin before forwarding ? | step 6 in flow diagram | Agreed with kieran mccarthy : NCMP wil only forward to client topic no handling tracking or any responses or status of request | ||||||||
| 8 | Handle non responding dmi-plugin | Agreed with kieran mccarthy : | |||||||||
| 9 | Should (can) NCMP check if 'MyTopic' specified by client exist | ||||||||||
| 10 | How to handle non-existing CM-Handled (id) | Suggestions
| |||||||||
| 11 | Overlap/clash with Deutsche Telekom user story:
| discussed in weekly ONAP meeting the DT user story is affect CPS-Core interface (not NCMP) and the requirement is to execute a query over ALL cm-handles (cached only?!) instead of a given list of cm-handles (~anchors) |
...
Flow Step | Short description | Message Details | Notes | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Bulk Get Request |
| Define new get operation "getResourceDataForCmHandles" into ncmp.yml | |||||||
| 2 | Ack Client Request |
| ||||||||
| 3 | DMI Bulk Request |
| The DMI PLugin should be told (included in request) the client topic so that NCMP does not have to 'remember' to relation between request id and client topic! Existing DMI endpoints are : /v1/ch/{cmHandle}/data/ds/ncmp-datastore:passthrough-operational: CPS Proposed : /v1/ch/batch/data/ds/ncmp-datastore:passthrough-operational: | |||||||
| 4 | Ack Client Request |
| ||||||||
| 5 | Kafka Messages from DMI to NCMP |
| ||||||||
| 6 | Kafka Message(s) from NCMP to Client |
| ||||||||
| 7 | Alternative for 4/5 → Non responding DMI. NCMP will have to create error message detailing cm-handles | See decision # 8 |
...