...
# | 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
{
|
------------------------------------------------------------------------------------------------------------ We had an internal review with some of our rApp colleagues around some of the recent proposed NCMP batch interface and they came back with some valid comment. The proposal is that we should not distinguish batch from bulk or other flavours of read/write. The aim is to only have a single flavour of interface for read or write for clients. Therefore the proposal is to drop “batch” from the interface URL and just act toward “data” (reads/writes/actions)
| |||||||||||||||||||||||||||
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.
| ||||||||||||||||||||||||||||
collapse | true | |||||||||||||||||||||||||||||
{
"$schema": "https://json-schema.org/draft/2019-09/schema",
"$id": "urn:cps:org.onap.cps.ncmp.events.async:batch-event-headers:1.0.0",
"$ref": "#/definitions/BatchEventHeaders",
"definitions": {
"BatchEventHeaders": {
"description": "The header information of the Batch event.",
"type": "object",
"javaType" : "org.onap.cps.ncmp.events.async.v1.BatchEventHeaders",
"properties": {
"eventId": {
"description": "The unique id for identifying the event.",
"type": "string"
},
"eventCorrelationId": {
"description": "The request id received by NCMP as an acknowledgement.",
"type": "string"
},
"eventTime": {
"description": "The time of the event. It should be in RFC format ('yyyy-MM- dd'T'HH:mm:ss.SSSZ').",
"type": "string"
},
"eventTarget": {
"description": "The destination topic to forward the consumed event.",
"type": "string"
},
"eventSource": {
"description": "The source of the event.",
"type": "string"
},
"eventType": {
"description": "The type of the Batch event.",
"type": "string"
},
"eventSchema": {
"description": "The schema of the Batch event payload.",
"type": "string"
},
"eventSchemaVersion": {
"description": "The schema version of the Batch event payload.",
"type": "string"
}
},
"required": [
"eventId",
"eventCorrelationId",
"eventTarget",
"eventType",
"eventSchema",
"eventSchemaVersion"
],
"additionalProperties": false
}
}
} |
Code Block | ||||
---|---|---|---|---|
| ||||
{
"eventId": "4cb32729-85e3-44d1-aa6e-c923b9b059a5",
"eventCorrelationId": "68f15800-8ed4-4bae-9e53-27a9e03e1911",
"eventTime": "2023-03-28T14:29:23.876+0000",
"eventTarget": "client-topic"
"eventSource": "dmi-plugin:enm-1"(dmi service name)
"eventType": "org.onap.cps.ncmp.event.model.BulkResponseEvent",
"eventSchema": "urn:cps:org.onap.cps.ncmp.events.async:batch-event-schema:1.0.0",
"schemaVersion": "1.0.0",
} |
Code Block | ||||
---|---|---|---|---|
| ||||
{ "$schema": "https://json-schema.org/draft/2019-09/schema", "$id": "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 cm handles" } } |
Need to follow schema structure there in #15 under Issues & Decisions section and it is agreed on
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.
- correlationid
- target
We have had some internal discussions including with some O-RAN standards representatives and one of the outcomes is that it would be good if we aligned with the some community standards for event header definitions. IT is proposed (initially from AT&T) that we should follow Cloud Native Computing Foundation (CNCF) specification as defined in their cloudevents incubator project.
More details see CPS Events Structure#CNCFCloudEventalignment
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
curl --location 'http: //localhost:8080/ncmp/v1/data?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", "targetIds": [ "836bb62201f34a7aa056a47bd95a81ed", "202acb75b4a54e43bb1ff8c0c17a8e08" ] }, { "operation": "read", "operationId": "14", "datastore": "ncmp-datastore:passthrough-running", "targetIds": [ "ec2e9495679a43c58659c07d87025e72", "0df4d39af6514d99b816758148389cfd" ] } ] }' |
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
{ "requestId": "4753fc1f-7de2-449a-b306-a6204b5370b3" } |
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
DMI Service 1 (POST): http://172.26.202.25:8783/dmi/v1/data?topic=my-topic-name&requestId=4753fc1f-7de2-449a-b306-a6204b5370b3 -> [ { "operationType": "read", "operationId": "14", "datastore": "ncmp-datastore:passthrough-running", "cmHandles": [ { "id": "ec2e9495679a43c58659c07d87025e72", "cmHandleProperties": { "neType": "RadioNode" } }, { "id": "0df4d39af6514d99b816758148389cfd", "cmHandleProperties": { "neType": "RadioNode" } } ] } ] DMI Service 2 (POST) : http://172.26.202.26:8783/dmi/v1/data?topic=my-topic-name&requestId=4753fc1f-7de2-449a-b306-a6204b5370b3 -> [ { "operationType": "read", "operationId": "12", "datastore": "ncmp-datastore:passthrough-operational", "options": "(fields=schemas/schema)", "resourceIdentifier": "parent/child", "cmHandles": [ { "id": "836bb62201f34a7aa056a47bd95a81ed", "cmHandleProperties": { "neType": "RadioNode" } }, { "id": "202acb75b4a54e43bb1ff8c0c17a8e08", "cmHandleProperties": { "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/data?&topic=my-topic-name
DMI-Plugin batch endpoint : http://172.26.202.25:8783/dmi/v1/data?topic=my-topic-name&requestId=e6fa4d26-4dc1-4877-aa3c-45e99f840708
- Mandatory Fileds :
- "operation": "read"
- "operationId": "12"
"datastore": "ncmp-datastore:passthrough-operational" - "targetIds": [ "0df4d39af6514d99b816758148389cfd", "ec2e9495679a43c58659c07d87025e72" ]
- Optional Fields :
- "options": "(fields=schemas/schema)"
- "resourceIdentifier": "parent/child"
event type proposal : from BatchDataXXXEvent to
DataOperationXXXEvent
For example : DataOperationResponseEvent
'eventType' value as below 'org.onap.cps.ncmp.events.BatchDataXXXEvent'
proposed Operation like :
'org.onap.cps.ncmp.events.DataOperationXXXEvent'
'batch' was the keyword use in the URL for this feature (now gone) but much code (classnames, variable names) etc uses this name still...
...
Field | Type | Description | Mandatory? | Notes | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
event | Event | The payload of an event | Mandatory | |||||||||
event.responses[0, 1, 2, ...] | Array | contains an array or batch response that includes both success and failure. | Mandatory | |||||||||
event.responses[0].operationId | String | specified to distinguish multiple operations using same cmhandleId | Mandatory | |||||||||
event.responses[0].ids | String | cmhandle-ids | Mandatory | Example : ["0df4d39af6514d99b816758148389cfd"] | ||||||||
event.responses[0].status-codestatusCode | String | Mandatory | Common NCMP defined error codes:
| |||||||||
event.responses[0].status-messagestatusMessage | String | Mandatory | Examples for code & message :
| |||||||||
event.responses[0].data | Object | Optional |
|
...