...
# | 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.
| Schema structure following #15 in Issues & Decisions section which is agreed on | 13 |
CPS-1557 - NCMP : forward bulk response messages to client topic |
Code Block | | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
urn:cps:org.onap.cps.ncmp.events.async:batch-event-schema:1.0.0", "$ref": "#/definitions/BatchDataResponseEvent", "definitions": { "BatchDataResponseEvent": { "description": "The payload of batch event.", "type": "object", "javaType" : "org.onap.cps.ncmp.events. |
async.v1.BatchEvent", |
|
" |
properties": { " |
event": { "description": "The |
content |
of |
Batch event.", "type": "object", " |
existingJavaType": |
|
"java.lang.Object", " |
additionalProperties": false |
|
|
|
|
|
|
|
} |
|
|
|
|
|
}, |
|
" |
required": |
[ |
"event" |
], |
" |
additionalProperties": |
false |
|
|
|
} |
}
} |
Code Block | ||||
---|---|---|---|---|
| ||||
{ "event": { |
|
" |
payload": " |
response of |
batch |
title | Sample bulk response |
---|---|
collapse | true |
cm handles"
}
} |
Schema structure following #15 in Issues & Decisions section which is agreed on
Schema for Bulk Response event forwarding to client specified topic
CPS-1557 - NCMP : forward bulk response messages to client topic
Not keeping the 'eventTarget' which comes from the (BulkResponseEvent(In progress of the structure agreement)).
Note: Will consider 'eventTarget', If it finalized the schema from
Jira | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Agreed on to keep one schema for both events (DMI → NCMP) and (NCMP → ClientApps)
How NCMP would forward response? (Response data : ref. message flow #6)
Jira | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
1. Do we need to send only one response containing all the requested cm handles ?
2. Send single response for each cm handle?
3. Single response message per DMI plugin?
kieran mccarthy - Please share your inputs on the above listed questions.
Batch interface message events structure | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
kafka Headers | |||||||||||||||||
Field | Type | Description | M=Mandatory, O=Optional | Notes | Decision | ||||||||||||
eventId | string | The unique id identifying the event | M | Generated by DMI-Plugin | Agreed with kieran mccarthy | ||||||||||||
eventCorrelationId | string | The request id passed by NCMP | M | It's requestId that NCMP sent to client as an ACK. Example : “request-1234" (UUID) |
| ||||||||||||
eventTime | string | The timestamp when original event occurred | O | Example of Internet date/time format. 1985-04-12T23:20:50.52Z This represents 20 minutes and 50.52 seconds after the 23rd hour of April 12th, 1985 in UTC. | Agreed with kieran mccarthy The timestamp should follow that on https://www.rfc-editor.org/rfc/rfc3339#section-5. This follows ISO 8601 and is what is used/referenced in 3GPP standards | ||||||||||||
eventTarget | string | The destination topic of the client | M | Example : my-topic | Agreed with kieran mccarthy | ||||||||||||
eventSource | string | The source of the event | O | Example : dmi-plugin:enm-1 (dmi service name) | Agreed with kieran mccarthy | ||||||||||||
eventType | string | The type of the event | M |
Example :
| kieran mccarthy Please confirm following : event type proposed name : BatchDataXXXEvent ? For example : BatchDataRequestEvent or BatchDataResponseEvent | ||||||||||||
eventSchema | string | The schema of the Batch event payload. | M |
Example :
| kieran mccarthy need your confirmation for below : In the current code we are are using like below : Can we use the same event naming pattern into value for consistency as all the other event schema follows the same ? 'urn:cps:org.onap.cps.ncmp.events.async:batch-event-schema:1.0.0'. instead of "urn:cps:org.onap.cps.ncmp.event.model.BatchEvent:v1“ | ||||||||||||
schemaVersion | string | The schema version of the Batch event payload. | M | For example a version might be 1.0.0 (without “v”) | On versioning O-RAN follows https://semver.org. kieran mccarthy Field name should be "eventSchemaVersion" for consistency as all the other event uses this name only? | ||||||||||||
Event Payload | |||||||||||||||||
event | Event | The payload of an event | M | Agreed with kieran mccarthy | |||||||||||||
event.response-code | String | The received status code of the response | M | common NCMP definned error codes:
| Agreed with kieran mccarthy
| ||||||||||||
event.response-message | String | M | Example :
| ||||||||||||||
event.data | array | The data payload | O | Agreed with kieran mccarthy NCMP will not amalgamate any data | |||||||||||||
event.data.id | String | cmhandle-id | M | Example : "2" | Agreed with kieran mccarthy | ||||||||||||
event.data.operationId | String | specified to distinguish multiple operations using same cmhandleId | M | Example : "12" | Agreed with kieran mccarthy NCMP wil not check uniqueness of 'operationId' | ||||||||||||
event.data.data | object | O |
| Agreed with kieran mccarthy NCMP will not amalgamate any data | |||||||||||||
evenr.error | object | O | Agreed with kieran mccarthy | ||||||||||||||
event.error.operations | array | M | Agreed with kieran mccarthy | ||||||||||||||
event.error.operations.operationId | String | M | mandatory - specified to distinguish multiple operations using same cmhandleId | Agreed with kieran mccarthy NCMP wil not check uniqueness of 'operationId' | |||||||||||||
event.error.operations.ids | array | cmhandle-ids | M | Example : ["cm-1",...,"cm-n"] | Agreed with kieran mccarthy |
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
curl --location 'http://localhost:8080/ncmp/v1/batch?include-descendants=true&topic=my-topic-name' \ --header 'Content-Type: application/json' \ --header 'Authorization: Basic Y3BzdXNlcjpjcHNyMGNrcyE=' \ --data '{ "operations": [ { "operation": "read", "operationId": "12", "datastore": "ncmp-datastore:passthrough-operational", "options": "(fields=schemas/schema)", "resourceIdentifier": "parent/child", "cmHandleIds": [ "da310eecdb8d44c2acc0ddaae01174b1" ] }, { "operation": "read", "operationId": "14", "datastore": "ncmp-datastore:passthrough-running", "resourceIdentifier": "parent/child", "cmHandleIds": [ "c748c58f8e0b438f9fd1f28370b17d47" ] } ] }' |
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
curl --location 'http://172.26.202.25:8783/dmi/v1/batch?topic=my-topic-name&requestId=e6fa4d26-4dc1-4877-aa3c-45e99f840708' \ --header 'Content-Type: application/json' \ --header 'Authorization: Basic Y3BzdXNlcjpjcHNyMGNrcyE=' \ --data '[ { "operationType": "read", "operationId": "12", "datastore": "ncmp-datastore:passthrough-operational", "options": "(fields=schemas/schema)", "resourceIdentifier": "parent/child", "cmHandleProperties": { "da310eecdb8d44c2acc0ddaae01174b1": { "neType": "RadioNode" } } }, { "operationType": "read", "operationId": "14", "datastore": "ncmp-datastore:passthrough-running", "resourceIdentifier": "parent/child", "cmHandleProperties": { "c748c58f8e0b438f9fd1f28370b17d47": { "neType": "RadioNode" } } } ]' |
Agreed with Csaba Kocsis and kieran mccarthy
requestId would be send as a path param from NCMP to DMI-plugin.
Example
NCMP batch endpoint : http://localhost:8080/ncmp/v1/batch?include-descendants=true&topic=my-topic-name
DMI-Plugin batch endpoint : http://172.26.202.25:8783/dmi/v1/batch?topic=my-topic-name&requestId=e6fa4d26-4dc1-4877-aa3c-45e99f840708
...