Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 169 Next »

Create 'bulk' version for org.onap.cps.ncmp.rest.controller.NetworkCmProxyController#getResourceDataForCmHandle to support multiple cm-handles (~ multiple anchors in in CPS-Core)

References

  1. CPS-1515 - Spike: Support multiple CM-Handles for NCMP Get Operation
  2. CPS-NCMP ↔ DMI-Plugin Interface Details Jakarta-R10
  3. CPS Events Structure

Requirements

Functional

#InterfaceRequirementAdditional Information
1REST CPS(-NCMP)-E-05Support batch read operation (new) using an asynchronous response on a client specified topicpayload includes list of cm handle ids
2REST DMI-I-01Support batch read operation (new) using an asynchronous response to an internal topicpayload includes list of (associated for this plugin) cm handles ids with their private (additional) properties

Error Handling

#Error ScenarioExpected behavior
1DMI Not respond to initial synchronous request with normal HTTP timeoutSpecial Error message (Kafka event)  including affected, and reason for all the handles in the message cm handles send to client topic detailing cm-handles
(per dmi plugin)
2Topic not supplied on CPS-E-05Return HTTP 501 (not implemented)
3Client specided Topic is not configuredLog error message only
4Non-existing cm-handle idSimilar message but different reason as specified #1 above

Capabilities

#ParameterExpectationNotes
1Response Time 1 Batch request<2 seconds (average)
  • Async response available on client topic
  • No delay in DMI PLugin (tested/measured using stub DMI Plugin)
2Batch-size200 cm handlesNo hardcoded limit
3Response payload size~2 KB per cm handlesPerformance test for capability should be tested with this average response size
4Maximum registered #cm handles 20,000This will effect the internal query time
5Supported # DMI PLugins10This might effect processing times
6Test Environment
 Click here to expand...
  1. CPS and NCMP

requests:
    cpu: 2000m
    memory: 2Gi
limits:
    memory: 3Gi
    cpu: 3000m

2. Postgres

requests:
    cpu: 4000m
    memory: 1Gi
 limits:
    memory: 3Gi
    cpu: 6000m


7Concurrent request1212 clients requests toward 1 NCMP simultaneously
8Request Frequency100 request/minShould not affect performance, does not need to be tested

Out-of-scope

  1. Support for multiple resource identifiers in one batch operation
  2. Support cached data batch requests: only passthrough datastores will be supported (see decision #2)
  3. NCMP does NOT keep track of request status to see if  it is completed, amalgamate responses or anything like that. It wil simply forward responses from the internal topic to the client topic.
  4. Access control

Assumptions

#

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.

4We 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

1Which operation(s) need support for multiple cm handles?
  1. Get
  2. Create
  3. Update (Put)
  4. Patch
  5. Delete

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 ?
(maybe just start with that, support cached data bulk request later)

agreed with kieran mccarthy :

all passthrough datastores will be supported

Not implemented (yet) response, for non passthrough datastores 

3URL  pattern for NCMP bulk endpoints

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 flavors of read/write. 

The aim is to only have a single flavor of interface for read or write for clients.  Therefore the proposal is to drop “batch” from the interface URL and just act toward “data”

Agreed with team kieran mccarthy 

POST http://localhost:8080/ncmp/v1/data&topic=my-topic-name

4keep 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

7Should 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

8Handle non responding dmi-plugin

Agreed with kieran mccarthy :
No response for 4b then send an error response to the topic given by client

9Should (can) NCMP check if 'MyTopic' specified by client existConsider Access Control too. For now NCMP can log error. Client is responsible for topic setup

Agreed with kieran mccarthy :
NCMP can log error when forward to 'client topic' Security not in scope (yet)

10How to handle non-existing CM-Handles (id)

Suggestions

  1. Silently ignore
  2. (initial) error response
    1. should we combine all errors in one message?

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: CPS-1377 - Getting issue details... STATUS ?!


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 CPS-1556 - Getting issue details... STATUS

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?

Need to follow schema structure there in  #15 under Issues & Decisions section and it  is  agreed on    

13

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 CPS-1556 - Getting issue details... STATUS

Agreed on to keep one schema for both events (DMI → NCMP) and (NCMP → ClientApps)

14

How NCMP would forward response? (Response data : ref.  message flow #6)

CPS-1556 - Getting issue details... STATUS

    1. Do we need to send only one response containing all the requested cm handles ?
    2. Send single response for each cm handle? This could lead to to much data in the event for large batch requests. Csaba Kocsis , Sourabh Sourabh and Toine Siebelink proposed to us single event for each cm handle
    3. Single response message per DMI plugin? Just is a list of IDS should be OK.

kieran mccarthy

kieran mccarthy  Confirmed in meeting  

15Message format for the batch interfaceWe 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.
Some non-standard headers wil need to be implemented as 'extensions' and names to be confirmed
  • correlationid
  • target

 kieran mccarthy 


More details see CPS Events Structure#CNCFCloudEventalignment

16NCMP will send only one request to each DMI

topic and requestId will be send as a path param from NCMP to DMI-plugin.

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 Fields:
      • "operation": "read"
      • "operationId": "12"
        "datastore": "ncmp-datastore:passthrough-operational"
      • "targetIds": [ "0df4d39af6514d99b816758148389cfd", "ec2e9495679a43c58659c07d87025e72" ]
  • Optional Fields: 
      • "options": "(fields=schemas/schema)"
      • "resourceIdentifier": "parent/child"

Agreed with Csaba Kocsis  and kieran mccarthy




17Feature Name (events)

event type proposal : from BatchDataEvent  to

DataOperationEvent

For example : DataOperationResponseEvent 

 'eventType' value as below 'org.onap.cps.ncmp.events.BatchDataEvent' 

proposed Operation like :

'org.onap.cps.ncmp.events.DataOperationEvent' 

'batch' was the keyword use in the URL for this feature (now gone) but much code (classnames, variable names) etc uses this name still...

kieran mccarthy and Team agreed on and some cost (1-2 days) is acceptable 

Event Format Definitions

Event Headers

CPS Events Structure

 AVC Subscription Event

Subscription Event Object

FieldTypeDescriptionHeaderPayloadNotesCloudEvents Mapping
versionstringThe event type versionX

included in dataschema
eventTypestring

The event type

X


standard (type)
source

X
NEW  see decision #18, value <clientId> (same as in payload) TBCstandard (source)
eventEventThe payload for an eventX
Defined by event object belowstandard (data) 

Event Object (cps:org.onap.cps.ncmp.events:avc-subscription-event:v1)

FieldTypeDescriptionHeaderPayloadNotes
subscriptionSubscriptionThe subscription details
XDefined by subscription object below
dataTypeDataType

The datatype content


XDefined by dataType object below
predicatesPredicates

Additional values to be added into the subscription


XDefined by predicates object below

Type: Subscription

FieldTypeDescriptionHeaderPayloadNotes
clientIDstring

The client ID


X
namestring

The name of the subscription


X
isTaggedboolean

optional parameter, default is false


Xdefault: false

Type: DataType

FieldTypeDescriptionHeaderPayloadNotes
dataspacestring

The dataspace name


X
dataCategorystring

The category type of the data


X
dataProviderstring

The provider name of the data


X
schemaNamestring

The name of the schema


X
schemaVersionstring

The version of the schema


X

Type: Predicates

FieldTypeDescriptionHeaderPayloadNotes
targetsarray

CM Handles to be targeted by the subscription


X
datastorestring

datastore which is to be used by the subscription


X
Xpath-filterstring

filter to be applied to the CM Handles through this event


X

Event Body (data)

  • The current proposal is to use the CNFC Event structure and library as detail in CPS Events Structure#CNCFCloudEventalignment
  • To prevent problems with large data request multiple response event will be sent for a successful read for each cm handle (id)
  • Error messages can contain information about single cm handle ids


Field 

Type

Description

Mandatory?

Notes

data
EventThe payload of an event

Mandatory

Cloud event standard (data) 
data.responses[0, 1, 2, ...]
Array contains an array or batch response that includes both success and failure.

Mandatory


data.responses[0].operationId
Stringspecified to distinguish multiple operations using same cmhandleId

Mandatory


data.responses[0].ids
Stringcmhandle-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.

data.responses[0].statusCode
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. 
data.responses[0].statusMessage
String

Mandatory

Examples for code & message :

statusCodestatusMessage
1"Successfully applied changes"
101"cmHandle(s) do not exist"
data.responses[0].dataObject

Optional

  1. In case of success :
    • Optional,  for write operations then no need to return configurations
      application/yang-patch+json | application/yang-data+json
  2. In case of failure :
    • Optional, any supplementary error data matching the error status-code


kieran mccarthy please confirm : we are using 'responseContent' as name of this field as 'data' is already used for cloud event standard payload.

Now it is like : data.responses[0].responseContent

 

Implementation

Bulk Request Message Flow

Message Flow details

Flow Step

Short description

Message Details

Notes

1

Bulk Get Request

NCMP batch endpoint 
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": "some option",
            "resourceIdentifier": "parent/child",
            "targetIds": [
                "836bb62201f34a7aa056a47bd95a81ed",
                "202acb75b4a54e43bb1ff8c0c17a8e08"
            ]
        },
        {
            "operation": "read",
            "operationId": "14",
            "datastore": "ncmp-datastore:passthrough-running",
            "targetIds": [
                "ec2e9495679a43c58659c07d87025e72",
                "0df4d39af6514d99b816758148389cfd"
            ]
        }
    ]
}'

Define new get operation "getResourceDataForCmHandles" into ncmp.yml

2Ack client Request
NCMP batch endpoint response (202->Accepted) 
{
    "requestId": "4753fc1f-7de2-449a-b306-a6204b5370b3"
}

3DMI Bulk Request
DMI service batch endpoint 
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": "some option",
        "resourceIdentifier": "parent/child",
        "cmHandles": [
            {
                "id": "836bb62201f34a7aa056a47bd95a81ed",
                "cmHandleProperties": {
                    "neType": "RadioNode"
                }
            },
            {
                "id": "202acb75b4a54e43bb1ff8c0c17a8e08",
                "cmHandleProperties": {
                    "neType": "RadioNode"
                }
            }
        ]
    }
]




4Ack NCMP Request
Response 202
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.
5Kafka Messages from DMI to NCMP
Batch Event Payload Schema 
{
  "$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
    }
  }
}  
Batch Event Payload 
{     
  "event": {
     "payload": "response of batch cm handles"
  } 
}

6Kafka Message(s) from NCMP to Client 
Table

Batch Event Payload 
{     
  "event": {
     "payload": "response of batch cm handles"
  } 
}
Single response format for all scenarios bot positive and error, just using optional fields instead
7Error for 4/5 → Non responding DMI, non existing CM Handles or any other error. NCMP will have to create error message detailing all cm-handle ids affect by that error.
Non responding DMI-plugin  
{
  "timestamp":"2023-03-01T23:00:00.345-0400", 
  "requestId":123,
  "error": "<error-message>",
  "Cmhandles":["cm-1",...,"cm-n"]
  }
Single response format for all scenarios bot positive and error, just using optional fields instead
See decision # 8

Proposed JIRAs :

PriorityComponentDescriptionJIRAsEstimateStatus
1DMI, NCMPBatch Response Event (DMI → NCMP) to Comply with Cloud Events

CPS-1723 - Getting issue details... STATUS

5 Days (M)New Requirement. 
2NCMPBatch Response Event (NCMP → Client App)

CPS-1724 - Getting issue details... STATUS

TBD 

Closed on  

3DMI-PluginAccept  datastore name as param into URL 

CPS-1550 - Getting issue details... STATUS

5 DaysDone
4NCMP Expose REST endpoint to accept collection of cm handles for GET operation (Passthrough only)

CPS-1553 - Getting issue details... STATUS

15 DaysDelivered, Pending task id RTD document only
5DMI-PluginExpose endpoint for ONAP not impl. and Stub impl. for testing/demo

CPS-1555 - Getting issue details... STATUS

5 DaysDone
6NCMPNCMP: Update existing REST endpoint that accepts bulk request for GET operation

CPS-1635 - Getting issue details... STATUS

5 Daysnew because Requirements changed
+5 days
7DMI-PluginDMI-Plugin : Update endpoint to accept bulk request

CPS-1636 - Getting issue details... STATUS

3 DaysClosed
8Stubbed DMI-PluginInclude code to send response messages to internal kafka topic with delay 

CPS-1556 - Getting issue details... STATUS

10 DaysOpen
9NCMP Forward response messages to client given kafka topic

CPS-1557 - Getting issue details... STATUS

5 Days

Closed

10NCMP Handle non-existing cm handles

CPS-1583 - Getting issue details... STATUS

5 Days


11NCMP Error handling for non-ready cm handle state

CPS-1614 - Getting issue details... STATUS

5 Days


12NCMP Handle non responding DMI-Plugin

CPS-1558 - Getting issue details... STATUS

5 Days


13CSIT test for demo

CPS-1560 - Getting issue details... STATUS

5 Days

Planning :

  • Allow for 2 more user stories each may take 1 weeks
  • Based on 2 resource working parallelly may take approx.. 8 weeks from 29 March 2023  
  • (updated after additional items where added) The estimated date for completion is   
  • No labels