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. 
2Using Liquibase v. Yang Model for storing new metadata per anchor in CPS Core
29-Sep-2023: We decided to use yang model to persisting delta notification subscription. No DB change is required. notification subscription information will be stored in Fragment table. 
3generic text field OK for future refinement, maybe consider json?
29-Sep-2023: subscription information will be persisted in JSON format 

Event Schema

proposal for notification schema:

Cloud event Definition


Element

Name

Parent

Type

Mandatory

Description

Format

(example) Value

1Headerid
StringYesrandom id for cloud event header. UUID is suggested

2source
StringYessource of informationfixed valueurn:cps:org.onap.cps
3specversion
StringYescloud event version specfixed value1.0
4type
StringYestype of eventfixed valuedataUpdateEvent
5dataschema
StringYesdata schemafixed valuecps:org.onap.cps:data-updated-event-schema:1.0.0
6Payloaddata
ObjectYesThe actual data payload. Details will be provided below.

7observedTimestampdataStringYesThe timespamp of the event. timestamp2024-01-17 12:34:43
8dataspaceNamedataStringYesThe dataspace name where data is changed.
dataspace01
9schemaSetNamedataStringNoThe schemaset name for which data is changed.
bookstore
10anchorNamedataStringYesThe anchor name for which data is changed.
anchor01
11operationdataStringYesThe operation performed on data. 

CREATE

UPDATE

DELETE


12xpathdataStringYesThe XPath which is changed 
/bookstore


Controlling Notification

 It is important to control the notifications for better performance. Notifications in cps-core will be controlled at Anchor level. By default notifications will be disabled for all anchors. notification can be enabled/disabled for an anchor or all anchors of a dataspace using below REST API. 

API to controlling delta notification 

Delta notification can be enabled/disabled by an additional admin API for list of anchors in a dataspace or all anchors in a dataspace. 

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


Request Body :

["anchor01", "anchor02"]

Note: if no anchors list provided in request body than notification will be enabled/disabled for all the anchors for given dataspace. 

Persisting notification subscription 

Add schema for notification subscription and add subscription information in to Fragment table when delta notification is subscribed. delete the fragment when delta notification is unsubscribed.

below actions will be performed when delta notification will be subscribed for the dataspace.  

  • schema set will be added to the dataspace when notification is subscribed.
  • An Anchor will be added to dataspace for notification subscription.
  • Subscription data will be added into fragment as per schema set. 

schema yaml file to be used as below. 

delta-notification.yaml 
module notifications {
    yang-version 1.1;
    namespace "org:onap:ccsdk:sample";

    prefix delta-notification;

    revision "2024-01-10" {
        description
        "Sample Model";
    }
	container deltanotification {

        leaf notification-subscription {
            type string;
        }
	}
}

Implementation details of delta notification

  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

10 Comments

  1. Lee Anjella Macabuhay

    action"
    for the actions such as 'add' 'delete' 'update'  — better to align some words with the rfc standard https://datatracker.ietf.org/doc/rfc9144/ (this is also still being discussed on the delta implementation code)

  2. Priyank Maheshwari

    Rajesh kumar 

    After internal discussion , I made my comments on the 3 possible approaches and out of these I think we can do more analysis on the third approach i.e ( while creating dataspace/anchor, configure to send delta notification. )

    As this approach closely defines the idea of CPS to be model-driven.  

    We can atleast start with this approach and then going forward we can make it more granular i.e for now dataspace and anchor level would be analysed and going forward we can have more granular notifications.

    Let us know your thoughts on this.


    FYI Toine Siebelink 

  3. Rajesh kumar

    Hi Priyank Maheshwari I agree with your suggestion. we will start configuring delta notification at anchor/dataspace label and it will be configurable while creating/updating an anchor/dataspace. 

  4. Priyank Maheshwari

    Sure Rajesh kumar 

    Maybe we can do a more detailed discussion around the agreed point. Or if you want to put in some details in the wiki page before changing any code.

    That would also work.

  5. Rajesh kumar

    Hi Priyank Maheshwari I updated the document with implementation details for controlling delta notification. please review. 

  6. Priyank Maheshwari

    Hi Rajesh kumar 

    Left inline comments .

    1. API signature to be modified a bit . What do you think ?
    2. Storing the notification value in DB or as YANG. Have a doubt regarding the in-service upgrade.

  7. Rajesh kumar

    Hi Priyank Maheshwari we can change signature of API as you suggested. regarding persisting notification value, we decided in community meeting to add another field in Anchor table for storing notification subscription. 

  8. Priyank Maheshwari

    Hi Rajesh kumar 

    Regarding storing the notification value , after that meeting I initiated an internal discussion and there the question of in-service upgradability came into thoughts.

    So now we have 2 possibilities , 

    1. to add a column in the anchor table and store the details
    2. introduce a new model just to store the anchor names which are subscribed / unsubscribed for the notification of the anchor.

    FYI Toine Siebelink 

  9. Rajesh kumar

    Hi Priyank Maheshwari I updated the document again with the approach to control the delta notification using a new model. as we discussed before, DT is willing to control delta notifications at dataspace level and hence I updated the document accordingly. I expect there will be challenges while configuring notification at anchor level because we cannot associate more than one schema for single anchor. we also need to have code please review and let us discuss about it. 

  10. Priyank Maheshwari

    Hi Rajesh kumar 

    I will have a look at it but as we want to have more granular control , the notification at the Dataspace level would be a wider scope.

    We would expect the solution to have Anchor level atleast. But lets have a discussion with key folks present and AGREE in the meeting before you start with the coding.

    FYI Toine Siebelink