CPS-2067 Granular control of CPS core notifications
- Rajesh Kumar
- Priyank Maheshwari
References
CPS-2067: Add support to control notifications at anchor levelIn Progress
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
Using this API notification can be subscribed/unsubscribed for an Anchor.
All the Anchors for a given Dataspace can be enabled/disabled for the notification.
Implementation
Create Notification Subscription
API: POST http://<IP:PORT>/cps/v2/notification-subscription
Delete Notification Subscription
API: DELETE http://<IP:PORT>/cps/v2/notification-subscription
Get Notification Subscription
API: DELETE http://<IP:PORT>/cps/v2/notification-subscription
Parameters
Parameter | In | Description |
|---|---|---|
xpath | Query | xpath of the dataspace/anchor to be subscribed or unsubscribed |
Persistence of notification subscriber information
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.
Entity | Description |
|---|---|
Dataspace Name | CPS-Admin |
Anchor Name | cps-notification-subscription |
schema set | cps-notification-subscription |
cps-notification-subscriptions@2024-06-18.yang |
Schemamodule cps-notification-subscriptions {
yang-version 1.1;
namespace "org:onap:ccsdk:sample";
prefix cps-notification-subscriptions;
revision "2024-08-05" {
description
"Sample Model";
}
container dataspaces {
list dataspace {
key "name";
leaf name {
type string;
}
container anchors {
list anchor {
key "name";
leaf name {
type string;
}
container xpaths {
list xpath {
key "path";
leaf path {
type string;
}
}
}
}
}
leaf-list subscriptionIds {
type string;
}
leaf topic {
type string;
}
}
}
}
JSON payload{
"cps-notification-subscriptions:dataspaces": {
"dataspace": [
{
"name": "ds01",
"anchors":{
"anchor": [
{
"name" : "anchor01",
"xpaths": {
"xpath": [
{
"path": "/xpath"
}
]
}
}
]
},
"subscriptionIds": ["0","1"],
"topic": "updated-events-1"
},
{
"name": "ds02",
"subscriptionIds": ["0"],
"topic": "updated-events-2"
}
]
}
}
|
When notification is subscribed for above payload, below records will be added in fragment table.
id | xpath | attributes | anchor_id | parent_id | schema_node_id |
|---|---|---|---|---|---|
1 | /dataspaces | {} | 6 |
|
|
2 | /dataspaces/dataspace[@name='ds02'] | {"name": "ds02", "subscriptionIds": ["0"], "topic": "updated-event-2"} | 6 | 1 |
|
3 | /dataspaces/dataspace[@name='ds01'] | {"name": "ds01", "subscriptionIds": ["0", "1"], "topic": "updated-event-1"} | 6 | 1 |
|
4 | /dataspaces/dataspace[@name='ds01']/anchors | {} | 6 | 3 |
|
5 | /dataspaces/dataspace[@name='ds01']/anchors/anchor[@name='anchor01'] | {"name": "anchor01"} | 6 | 4 |
|
6 | /dataspaces/dataspace[@name='ds01']/anchors/anchor[@name='anchor01']/xpaths | {} | 6 | 5 |
|
7 | /dataspaces/dataspace[@name='ds01']/anchors/anchor[@name='anchor01']/xpaths/xpath[@path='/xpath'] | {"path": "/xpath"} | 6 | 6 |
|
Notification scenarios
Scenario | Description | |
|---|---|---|
| 1 | day 0 |
|
| 2 | enable notification for a dataspace and all of its anchors | xpath '/dataspaces/dataspace[@name='ds-name']' and attributes '{"name": "ds01", "subscriptionIds": ["0"]}' will be added |
| 3 | when a new dataspace will be created | notification will be disabled for newly created dataspace. clients need to subscription API to enable notification |
| 4 | when a new anchor will be created | for newly created anchors notification will be disabled. clients need to call subscription API to enable notification for newly created anchor |
| 5 | Disable notification for whole dataspace | all notifications for the dataspace will be disabled. |
| 6 | Disable notification for specific anchor | If notification is subscribed for the anchor than client can disable notifications for the Anchor |
| 7 | Enable notification for dataspace and disable for few anchors | First Anchors should be subscribed than only client can unsubscribe notification for the Anchor. |
| 8 | notification subscription for same dataspace or anchor using different subscription ids. | subscription ids will be updated in attributes field (future scope) for similar subscriptions. |
| 9 | when a new dataspace or anchor added | notification will be disabled for newly created dataspace or anchor. |
Limitations
# |
|
|---|---|
1 | Dataspace name, anchor name or xpath with not be verified |
2 |
|
Schema v/s non-schema persistence
Using Schema | Without Schema |
|---|---|
Pros:
Cons:
| Pros:
Cons:
|
Common code for cps-core and ncmp
we also propose to make below common classes in cps service which will be reused in NCMP service during model initialization for notification subscription. it will reduce the duplicate code in NCMP and CPS service.
Class | Class type | package | methods |
|---|---|---|---|
ModelLoader | Interface | org.onap.cps.init |
|
AbstractModelLoader implements ModelLoader | Abstract | org.onap.cps.init |
|
Class Diagram
