...
| # | Error Scenario | Expected behavior |
|---|---|---|
| 1 | DMI Not respond to initial synchronous request with normal HTTP timeout | Special Error message send to client topic detailing cm-handles |
| 2 | Topic not supplied on CPS-E-05 | Return HTTP 501 |
| 3 | Client specided Topic is not configured | See open issue #9 |
| 4 | Non-existing cm-handle id | See open issue #10 |
Capabilities
| # | Parameter | Expectation | Notes |
|---|---|---|---|
| 1 | Response Time 1 Batch request | <2 seconds |
|
| 2 | Batch-size | 200-300 cm handles | No hardcoded limit |
| 3 | Response payload size | ?? KB | Performance test for cabilitie should be tested with this average response size |
| 4 | Maximum registered #cm handles | 20,000 | This will effect the internal query time |
| 5 | Supported # DMI PLugins | <30 (TBC) | This might effect processing time |
| 6 | Environment |
...
# | 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 |
| 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 |
| 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 with Deutsche Telekom | Sourabh Sourabh discussed Lee Anjella Macabuhay who confirmed there s no overlap | TBD |
...
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 eb be told (included in request) the client topic so that NCMP does not have to 'remember' to relation between request id and client topic! | |||||||
| 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 |
...