dCreate Create 'bulk' version for org.onap.cps.ncmp.rest.controller.NetworkCmProxyController#getResourceDataForCmHandle to support multiple cm-handles (~ multiple anchors in in CPS-Core)
...
CPS-1515- Spike: Support multiple CM-Handles for NCMP Get Operation
Support batch read operation (new) using an asynchronous response on a client specified topic
payload includes list of cm handle ids
2
REST DMI-I-01
Support batch read operation (new) using an asynchronous response to an internal topic
payload includes list of (associated for this plugin) cm handles ids with their private (additional) properties
...
#
Assumption
Notes
1
Proprietary options or not in the scope of this analysis.
agreed with kieran mccarthy ; these are optional parameters (name-value pairs) not interpreted by NCMP but can be interpreted by proprietary plugins In the future "scope" might become standardized instead of proprietary but that wil be achieved through a separate requirement
2
same xpath (resourceIdentifierInQuery) for all cm handles or different for each cm handle
agreed with kieran mccarthy ; if different resources are required on the same cm-handle the client wil send another (batch) request
3
options, resourceIdentifier is optional for bulk operations.
operation, datastore and cmhandleIds are mandatory fields
agreed with CPS team.
4
We are not merging any duplicate cm handles while sending request to dmi-plugin
agreed
5
Get batch operation does not support includeDescendants as it is impl. for
pass through datastore only
ncmp-datastore:passthrough-running and
ncmp-datastore:passthrough-operational
agreed on
Issues & Decisions
#
Issue
Notes
Decision
1
Which operation(s) need support for multiple cm handles?
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)
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)
1) Agreement required on the structure of the response. Please see response structure below. 2) Does 'eventTime' field which holds the timestamp of the bulk response event, required or can it be dropped?
Code Block
title
Batch Event Headers Schema
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
}
}
}
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.
15
Message format for the batch interface
some non-standard headers wil need to be implemented as 'extensions' and names to be confirmed
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
'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 classes (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"] Note: Ids array should contain only a single element in the array in case of success messages and In case of error it can have any number of elements.
event.responses[0].status-code
String
Mandatory
Common NCMP defined error codes:
status-code 0-99 is reserved for any success response
status-code from 100 to 199 is reserved for any failed response.
event.responses[0].status-message
String
Mandatory
Examples for code & message :
status-code
status-message
1
"Successfully applied changes"
101
"cmHandle(s) do not exist"
event.responses[0].data
Object
Optional
In case of success :
Optional, for write operations then no need to return configurations application/yang-patch+json | application/yang-data+json
In case of failure :
Optional, any supplementary error data matching the error status-code
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 NCMP Request
Code Block
title
Response 202
collapse
true
202 is non-committal, meaning that there is no way for the HTTP to later send an asynchronous response indicating the outcome of processing the request. It is intended for cases where another process or server handles the request, or for batch processing.
CPS-1515 - Spike: Support multiple CM-Handles for NCMP Get Operation