Versions Compared

Key

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

Table of Contents

References

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

Issues & Decisions

#

Issue

Notes

Decisions

1

Use anchor objects instead of just the anchor names. ( this is to make sure the YANG schema is flexible enough and also same in the REST side)

Requires we agree on the REST endpoint and request body and corresponding YANG schema to store the metadata.


2

Wildcard character to subscribe/unsubscribe all the anchors in a given dataspace.

Need to agree on the wildcard character.

Propose to have a single ["*"] to subscribe or unsubscribe.






Description

We want to implement a granular approach to control cps notifications. it will help in performance improvement by suppressing the unwanted messages in Kafka message stream 

Proposal

We propose to implement an admin API to control (Enable/Disable) the Kafka notifications at Anchor level. This API provides below functionalities 

  1. Using this API notification can be subscribed/unsubscribed for an Anchor. 
  2. All the Anchors for a given Dataspace can be enabled/disabled for the notification.

Implementation

API 

URL : PUT http://<IP:PORT>/cps/v2/dataspaces/{dataspace-name}/notification-subscription/{subscription}

Query Parameters:

ParameterDescription
dataspace-name

dataspace name

subscription

subscribe or unsubscribe


Code Block
languagetext
titleRequest Payload
["anhcor01", "anchor02", "anchor03" ...]

Note: To enable all the anchors of the given dataspace, we can use empty request payload

Persistence (without schema)

 we propose to persist notification subscription information using two different approaches 1. using an YANG schema and 2. without using schema. this is TBD to decide on best approach. 

Information about the subscription of notification will be persisted in Fragment table. For Example, if the notification is unsubscribed by anchor_id 28, fragment table will have below entry


Note : Since a new xpath "/notification-subscription" is added for notification subscription, we need to ignore this xpath  while getting data nodes for root xpath.  

Image Added

The above entry from fragment table will be deleted when anchor is subscribed to notification. 

Attributes field is empty because we don't need any further granular control of notification. In future if we need to implement further granular control of notification, we can use attributes fields 

Persistence using NEW dedicated YANG schema 

APIsDescription
POST http://<IP:PORT>/cps/v2/notification-subscriptionsubscribe cps notification
DELETE  http://<IP:PORT>/cps/v2/notification-subscriptionunsubscribe cps notification


We can create different dataspace and anchor specially for cps notification to persist notification subscription information. We propose to create below dataspace, schema and anchor for notification subscription.

EntityDescription
Dataspace NameCPS-Admin
Anchor Namecps-notification-subscription
schema setcps-notification-subscription
cps-notification-subscriptions@2024-06-18.yang


Code Block
titleSchema
collapsetrue
module subscription {
    yang-version 1.1;
    namespace "org:onap:ccsdk:sample";

    prefix notification-subscription;

    revision "2024-07-05" {
        description
            "Sample Model";
    }
    container cps-notification {
      list dataspaces {
        key "name";
        leaf name {
          type string;
        }
        list anchors {
          key "name";
          leaf name {
            type string;
          }
          list xpaths {
            key "xpath";
            leaf xpath {
              type string;
            }
          }
        }
      }
    }
}


Code Block
titleJSON payload
collapsetrue
{
    "notification-subscription": {
	    "dataspaces": [
		    {
			    "name": "dataspace01"
			},
			{
			    "name": "dataspace02",
			   "anchors": [
				    {
					    "name": "anchor01"
					},
					{
					    "name": "anchor02"
					}
				]
			},
			{
			    "name": "dataspace03",
			    "anchors": [
			     {
			         "name": "anchor01",
				     "xpaths" : [
				         {
						.    "xpath": "/bookstore/categories[@code='01']"
						 },
						 {
							 "xpath": "/bookstore/categories[@code='02']"
						 }
					 ]
				}
				]
			}	
		]
		
	}
}


When Notification is unsubscribed for above payload, below records will be added in fragment table. 

dataspace01 : all anchors unsubscribed

dataspace02: list of anchors unsubscribed

dataspace03: list of anchors and xpaths unsubscribed 

  

idxpathattributesanchor_idparent_idschema_node_id
1/notification-subscription/dataspaces[@name='dataspace01']
6

2/notification-subscription/dataspaces[@name='dataspace02']/anchors[@name='anchor01']
6

3/notification-subscription/dataspaces[@name='dataspace02']/anchors[@name='anchor02']
6

4/notification-subscription/dataspaces[@name='dataspace03']/anchors[@name='anchor01']

[.

"/bookstore/categories[@code='01", "/bookstore/categories[@code='02"

]

6

Schema v/s non-schema persistence

Using SchemaWithout Schema

Pros:

  1. consistent with cps modules. 

Cons:

  1. Need to create dataspace, anchor and schema in advance.
  2. schema is redundant because of fixed payload structure 

Pros:

  1. Simplify 

Cons:

  1. Not consistent with other modules of CPS.
  2. Extra cps path in fragment table. need to ignore these xpaths in get datanodes API.