Skip to end of metadata
Go to start of metadata

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

Compare with Current View Version History

« Previous Version 17 Next »

Objective

As of current implementation in cps core, after the update operation, entire configuration is sent as Kafka Notification. we are proposing to send only changed configuration as delta report in notification. It will help to understand what configuration exactly changed for the anchor. 

Issues & Decisions

#IssueNotesDecision
1Do we need to update existing update notification to send delta notification or delta notification along with existing notification. 
29-Sep-2023: We decided to implement delta notification separately without changing the existing update notification. 




Event Schema

For delta notification we can use the existing cps data update event schema (cps-data-update-event-schema.json). 

#

1idUUID of the event
2source
urn:cps:org.onap.cps
3schema
urn:cps:org.onap.cps:data-updated-event-schema:v1
4type
org.onap.cps.data-updated-delta-event
5content
{
"operation": "UPDATE",
"anchorName": "Anchor1",
"dataspaceName": "dataspace1",
"schemaSetName": "schemaset1",
"observedTimestamp": timestamp,
"data":
data body 
[
  {
    "action": "ADD",
    "xpath": "/bookstore/categories/[@code=3]",
    "payload": {
      "code": 3,
      "name": "kidz"
    }
  },
  {
    "action": "DELETE",
    "xpath": "/bookstore/categories/[@code=1]",
    "payload": {
      "code": 1,
      "name": "Fiction"
    }
  },
  {
    "action": "UPDATE",
    "xpath": "/bookstore/categories/[@code=2]",
    "payload": {
      "name": "Comic"
    }
  }
]
}

Controlling Notification

 It is important to control the delta notification for better performance. we need to decide on below options to control delta notification.

OptionPros and Cons Decision
Send delta notification for the update operation when update request contains optional query parameter to receive notification. 

Pros:

  1. Dynamically control notification and per request level. 

Cons: 

  1. there could be issue with access control

Configure dataspace/anchor in yaml file to allow delta notification.

Pros:

  1. Only allowed dataspace/anchor's delta update will be sent in notification

Cons:

  1. Not practical because we can't control the notification dynamically.  

while creating dataspace/anchor, configure to send delta notification. 

Pros: 

  1. control the notification dynamically.

Cons:

  1. Need to persist notification information in DB. 
We decided to try this approach. detailed implementation provided below. 


Implementation of controlling delta notification 

Delta notification can be enabled/disabled by an additional admin API for a given anchor name. New API will be added as below.


API :  PUT https://IP:PORT/cps/api/v2/dataspace/<dataspace-name>/deltanotification


Request body:

[

{

"anchorName": "anchor01",

"subscribeDeltaNotification": true

}, 

{

"anchorName": "anchor02",

"subscribeDeltaNotification": true

}

]


Additional field will be added to Anchor table to persist delta notification subscription. newly added field details are as below.  



Updated TableAnchor
new field name notification
typetext
example true (string). change later. 

Open questions to be discussed:

OptiondescriptionDecision

Is it OK to modify Postgres tables instead of using a yang modelled data approach... (this will require Liquibase steps)


TD : Toine Siebelink need to discuss with Architects and update

generic text field OK for future refinement, maybe consider json?



Implementation details

  1. For data nodes update operation, generate delta report by comparing previous and current configuration after successful update. 
  2.  Process data update delta event and send notification as described in event schema above. 
  • No labels