...
# | 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 non passthrough datastores | ||||||||||||||||||||||||||
3 | URL pattern for NCMP bulk endpoints |
----------------------------------------------------------------------------------------------------------------------- Meeting : kafka message schema & batch interface extension POST http://localhost:8080/ncmp/v1/batch&topic=my-topic-name { |
------------------------------------------------------------------------------------------------------------ | ||||||||||||||||||||||||||
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 | Consider Access Control too. For now NCMP can log error. Client is responsible for topic setup | Agreed with kieran mccarthy : | ||||||||||||||||||||||||||
10 | How to handle non-existing CM-Handles (id) | Suggestions
| Agreed with kieran mccarthy : Additional error (messages) response with all cm-handles that cannot be resolved, also a separate error message wil be sent for each failed DMI | ||||||||||||||||||||||||||
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) | |||||||||||||||||||||||||||
12 | Schema of bulk response
| 1) Agreement required on the structure of the response. Please see response structure below.
| |||||||||||||||||||||||||||
13 | Not keeping the 'eventTarget' which comes from the BulkResponseEvent. Note: Will consider 'eventTarget', If it finalized the schema from
|
<Note. use green for closed issues, yellow for important ones if needed>
Implementation
Bulk Request Message Flow
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Message Flow details
14 | How NCMP would to forward response? (Response data : ref. message flow #6)
| 1. Do we need to send only one response containg all the requested cm handles ? 2. Send single response for each cm handle? 3. Single response message per dmi plugin? |
<Note. use green for closed issues, yellow for important ones if needed>
Implementation
Bulk Request Message Flow
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
Message Flow details
Flow Step | Short description | Message Details | Notes | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Bulk Get Request |
| |||||||||||||||
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! | ||||||||||||||
4 | Ack Client Request |
| |||||||||||||||
5 | Kafka Messages from DMI to NCMP |
| |||||||||||||||
6 | Kafka Message(s) from NCMP to Client Table |
| |||||||||||||||
7 | Alternative for 4/5 → Non responding DMI. NCMP will have to create error message detailing cm-handles | See decision # 8 and 9 | |||||||||||||||
8 | Response message structure ? (Flow no. 5) Non responding DMI-plugin |
| |||||||||||||||
9 | Response message structure ? (Flow no. 5) Non existing cm handles |
| |||||||||||||||
10 | Non Ready cm handles |
| |||||||||||||||
11 | URL pattern for DMI-Plugin bulk endpoints Existing DMI endpoints are : /v1/ch/{cmHandle}/data/ds/{datastore-name} datastore-name:
...&topic=topicParamInQuery CPS Proposed : /v1/ch/batch/data/ds/{datastore-name} ...&topic=topicParamInQuery cm handle ids and requestid into body |
Proposed JIRAs :
endpoints | Existing DMI endpoints are : /v1/ch/{cmHandle}/data/ds/{datastore-name} datastore-name:
...&topic=topicParamInQuery CPS Proposed : /v1/ch/batch/data/ds/{datastore-name} ...&topic=topicParamInQuery cm handle ids and requestid into body |
Proposed JIRAs :
# | Component | Description | JIRAs | Estimate | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | DMI-Plugin | Accept datastore name as param into URL |
| 5 Days | ||||||||||||||||||||||||||
2 | NCMP | Expose REST endpoint to accept collection of cm handles for GET operation (Passthrough only) |
| 15 Days | ||||||||||||||||||||||||||
3 | DMI-Plugin | Expose endpint for ONAP not impl. and Stub impl. for testing/demo |
| 5 Days | ||||||||||||||||||||||||||
4 | Stubbed DMI-Plugin | Include code to send response messages to internal kafka topic with delay | ||||||||||||||||||||||||||||
# | Component | Description | JIRAs | Estimate | ||||||||||||||||||||||||||
1 | DMI-Plugin | Accept datastore name as param into URL |
| 5 10 Days | ||||||||||||||||||||||||||
25 | NCMP | Expose REST endpoint to accept collection of cm handles for GET operation (Passthrough only)Forward response messages to client given kafka topic |
| 15 5 Days | ||||||||||||||||||||||||||
6 | 3NCMP | DMI-Plugin | Expose endpint for ONAP not impl. and Stub impl. for testing/demo | Handle non-existing cm handles |
| |||||||||||||||||||||||||
Jira | server | ONAP Jira
| 1555
| 5 Days | ||||||||||||||||||||||||||
7 | 4 | Stubbed DMI-Plugin | Include code to send response messages to internal kafka topic with delay | NCMP | Error handling for non-ready cm handle state |
| 1556
| 10 5 Days | ||||||||||||||||||||||
58 | NCMP | Forward response messages to client given kafka topicHandle non responding DMI-Plugin |
| 5 Days | ||||||||||||||||||||||||||
69 | NCMP | NCMP | NCMP: Update existing REST endpoint that accepts bulk request for GET operationHandle non-existing cm handles |
| 5 Days | 7 | NCMP | Error handling for non-ready cm handle state |
| 5 DaysTBD | ||||||||||||||||||||
10 | NCMP | MI-Plugin | Handle non responding DMI-Plugin : Update endpoint to accept bulk request |
| 1558
| 5 DaysTBD | ||||||||||||||||||||||||
911 | CSIT test for demo |
| 5 Days |
...