Impl. Proposal CM Subscriptions : Creating/Merging( Positive Scenarios )

References

https://lf-onap.atlassian.net/browse/CPS-1870

https://lf-onap.atlassian.net/browse/CPS-1812

Assumptions

Issues & Decisions

Overview

This page only contains the details used for starting the development on the Merging of Subscriptions use case. Just the straight forward scenarios will be covered and the overall solution will be build on top of it.

Schema Definitions

1. DME to NCMP Subscription Request
   
   

   
   Example

   DME to NCMP Subscription Request

   id : random-UUID version : "1.0" source : "DME" type : "subscriptionCreateRequest", dataschema : org.onap.ncmp.cm.subscription:1.0.0  { "data": { "subscriptionId": "unique subscription id", // mandatory "predicates": [ { “targetFilter” : list of cmhandles, // mandatory "scopeFilter" : { "datastore": “ncmp-datastore:passthrough-operational or ncmp-datastore:passthrough-running", // optional. default is passthrough-operational "xpath-filter": list of valid xpaths // mandatory } } ] }

   
   
   

2. NCMP to DMI-Plugin Subscription Request
   
   

   Example

   NCMP to DMI-Plugin Subscription Request

   id : random UUID version : 1.0 source : "NCMP" type : "subscriptionCreateRequest" dataschema : org.onap.ncmp.dmi.cm.subscription:1.0.0 correlationId ( concatenation of subscriptionId and dmi-plugin-name with a separator) { "data": { "cmhandles" : [ // mandatory { "cmHandleId": "cmhandle1", "privateProperties": {...} }, { "cmHandleId": "cmhandle2", "privateProperties": {...} }, { "cmHandleId": "cmhandle3", "privateProperties": {...} } ] "predicates": [ { “targetFilter” : [“cmHandle1”, “cmHandle2”, "cmhandle3"], // mandatory "scopeFilter" : { "datastore": “ncmp-datastore:passthrough-operational or ncmp-datastore:passthrough-running", // optional. default is passthrough-operational "xpathFilter": list of valid xpaths // mandatory } },   { “targetFilter” : [“cmHandle1”, “cmHandle2”, "cmhandle3"], "scopeFilter" : { "datastore": “ncmp-datastore:passthrough-operational or ncmp-datastore:passthrough-running", // optional. default is passthrough-operational "xpathFilter": list of valid xpaths * } }  ] }

   
   
   

3. DMI-Plugin to NCMP Subscription Response
   
   

   
   Example

   DMI-Plugin to NCMP Subscription Response

   id : random UUID version : "1.0" source : <dmi-plugin-name> type : "subcriptionCreateResponse" dataschema : org.onap.ncmp.dmi.cm.subscription:1.0.0 correlationid : ( concatenation of subscriptionId and dmi-plugin-name with a separator) { "data" : { "statusCode": "1/104", // mandatory "statusMessage" : "ACCEPTED/REJECTED" // mandatory } }

   
   
   

4. NCMP to DME Subscription Response
   
   

   
   Example

   NCMP to DME Subscription Response

   id : random UUID version : "1.0" source : "NCMP" type : "subcriptionCreateResponse", dataschema : org.onap.ncmp.cm.subscription:1.0.0, correlationId : <subscriptionId> { "data": { "subscriptionId": "sample-subscription-id", // mandatory   "accepted-targets" : ["ch-1", ...], // optional "rejected-targets" : ["ch-1", ...], // optional "pending-targets" : ["ch-1", ...], // optional } }

Storage Solutions

Proposed Data Storage

Use a combination of

1. Database (yang modelled) for permanent subscription details, subscribers, predicates

2. In-Memory (hazelcast) for transient subscription details:  state (acceptep, rejected, pending)

Example Flow 1: First Subscription

• We have the below configuration managed by CPS-NCMP
  
  

1. We get a Subscription Create Request with unique subscription-id and a list of predicates(list of targets , datastore and list of filters)
   
   

   Subscription Create Message

   { "subscriptionId" : "A-10", "predicates" : [ { "targets": [ch-1,ch-2], "datastore" : "ncmp-datastore:passthrough-operational", "datastore-xpath-filter" : ["p1/c1","p2/c2"] }, { "targets": [ch-3], "datastore" : "ncmp-datastore:passthrough-operational", "datastore-xpath-filter" : ["p3/c3"] } ] }

2. We maintain a distributed datastructure in Hazelcast to keep track of the request and response to the client.
   
   

3. Read the requests from the distributed data structure and form the request for the DMI-Plugin and publish it to the internal kafka channel.

4. If the DMI-Plugin responds back within the configured time , so the request will either be ACCEPTED or REJECTED.

   1. if whole subscription request is ACCEPTED , update the distributed data structure and then store the subscription to the database.

   2. if whole subscription request is REJECTED , update the distributed data structure and send back the response to the client and no need to store anything to database.

   3. if the DMI Plugin fails to respond then the status would remain PENDING only in the distributed datastructure as there is no change.
      
      

      
      If there are no more PENDING requests , then we can right away send the response without updating the cache.

5. We store the "ActiveSubscriptions" using a new model which will look like below.
   
   

6. Now based on whatever we have in the distributed map , we will send the response to the clients and may be clear the in-memory structure if required.