Versions Compared

Old Version 173

changes.mady.by.user kieran mccarthy

Saved on

compared with

New Version 174

changes.mady.by.user Sourabh Sourabh

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

#

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:

Jira
serverONAP Jira
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyCPS-1377
?!


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

Jira
serverONAP Jira
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyCPS-1556

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

Jira
serverONAP Jira
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyCPS-1556

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)

Jira
serverONAP Jira
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyCPS-1556

    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 

18What would be the field name of response data?data.responses[0].data

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

Sourabh Sourabh Suggest to use "result".  This is after all where the actual result output.  the other tags in responses[x] are status related to the request  :

                        data.responses[0].result

Event Format Definitions

Event Headers

...

  • 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
  • event will be sent for a successful read for each cm handle (id)
  • Error messages can contain information about single cm handle ids


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. 

    Examples for code & message :

    "cmHandle(s) do not exist"

    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

    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


    data.responses[0].statusMessageoperationId
    		String

    Mandatory

    statusCodestatusMessage
    1"Successfully applied changes"
    101specified to distinguish multiple operations using same cmhandleId

    Mandatory


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

    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
    statusMessage
    		String

    Mandatory

    Examples for code & message :

    statusCodestatusMessage
    1"Successfully applied changes"
    101"cmHandle(s) do not exist"


    Sourabh Sourabh Suggest to use "result".  This is after all where the actual result output.  the other tags in responses[x] are status related to the request  :

                            data.responses[0].data    		Object

    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
    result

    Implementation

    Bulk Request Message Flow

    ...