Versions Compared

Key

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

Table of Contents

References

Jira
serverONAP Jira
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyCPS-1870


Assumptions

#

Issue

Notes

Decisions

1




...

  1. DME to NCMP Subscription Request

    Code Block
    titleDME to NCMP Subscription Request
    linenumberstrue
    collapsetrue
    Header values ( all cloud events header )
    
    
    {
      "data": {
        "subscriptionId": "unique subscription id",
        "predicates": [
    	{
            “targets” :  list of cmhandles
            "datastore": “ncmp-datastore:passthrough-operational or ncmp-datastore:passthrough-running",
            "datastore-xpath-filter": list of valid xpaths
      
        }
    	]
    }



  2. NCMP to DMI-Plugin Subscription Request

    Code Block
    titleNCMP to DMI-Plugin Subscription Request
    linenumberstrue
    collapsetrue
    // correlationId for tracking
    {
      "data": {
       
    	"cmhandles" : [
    	{
    		"cmHandleId": "cmhandle1",
    		"private-properties": {...} 
    	},
    	{
    		"cmHandleId": "cmhandle2",
    		"private-properties": {...}
    	},
    	{
    		"cmHandleId": "cmhandle3",
    		"private-properties": {...}
    	}
    	]
        "predicates": [
    	{
            “targets” :  [“cmHandle1”, “cmHandle2”, "cmhandle3"]
            "datastore": “ncmp-datastore:passthrough-operational",
            "datastore-xpath-filter": ["p1/c1", "p2/c2"]
      
        },
    	{
            “targets” :  [“cmHandle1”]
            "datastore": “ncmp-datastore:passthrough-running",
            "datastore-xpath-filter": ["p3/c3", "p4/c4"]
        }
    	]
    }



  3. DMI-Plugin to NCMP Subscription Response

    Code Block
    titleDMI-Plugin to NCMP Subscription Response
    linenumberstrue
    collapsetrue
    Headers will have relevant fields including the subscriptionId
    
    // correlationId for tracking - to link with NCMP. ( get clarity )
    { 
    "data" : {
    
       "dmiName":"<dmiName>", 
       "statusCode": "1", // open issue for the status codes ( whether to use the same for DMI to NCMP  as for NCMP to Clients)
       "statusMessage" : "accepted/rejected"
    }
    }



  4. NCMP to DME Subscription Response

    Code Block
    titleNCMP to DME Subscription Response
    linenumberstrue
    collapsetrue
    Headers will have relevant fields including the subscriptionId
    
    {
      "data": {
    		"subscriptionId": "sample-subscription-id",
    		"accepted-targets" : ["ch-1", ...],
    		"rejected-targets" : ["ch-1", ...],
    		"pending-targets" : ["ch-1", ...],
      }
    }



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

    #

    cmhandle

    dmi-plugin

    1ch-1dmi-1
    2ch-2dmi-1
    3ch-3dmi-2
    4ch-4dmi-2
    5ch-5non-responding-dmi


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

    Code Block
    titleSubscription Create Message
    linenumberstrue
    collapsetrue
    {
    "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 persist the incoming request as is in our persistent store using a relevant subscription model ( this model also needs to be revised )
  3. We also maintain a distributed datastructure in Hazelcast to keep track of the request and response to the client.

    SubscriptionId

    dmi-plugin

    affectedCmHandles

    status

    A-10dmi-1["ch-1","ch-2"]PENDING
    A-10dmi-2["ch-3"]PENDING


  4. Read the requests from the distributed data structure and form the request for the DMI-Plugin and publish it to the internal kafka channel.
  5. 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 ActiveSubscriptions in cps-cache.
    2. if whole subscription request is REJECTED , update the distributed data structure and send back the response to the client.
    3. if the DMI Plugin fails to respond then the status would remain PENDING only as there is no change.

      SubscriptionId

      dmi-plugin

      affectedCmHandles

      status

      A-10dmi-1["ch-1","ch-2"]ACCEPTED
      A-10dmi-2["ch-3"]REJECTED


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

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

    SubscriptionId

    cmHandle

    filter

    datastore

    A-10ch-1p1/c1ncmp-datastore:passthrough-operational
    A-10ch-1p2/c2ncmp-datastore:passthrough-operational
    A-10ch-2p1/c1ncmp-datastore:passthrough-operational
    A-10ch-2p2/c2ncmp-datastore:passthrough-operational


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


Example Flow 2: Second Subscription (merge)


  1. We get a new subscription create request.

    Code Block
    title2nd Subscription Create Message
    linenumberstrue
    collapsetrue
    {
    "subscriptionId" : "B-52",
    "predicates" : [
      {
        "targets": [ch-2],
        "datastore" : "ncmp-datastore:passthrough-operational",
        "datastore-xpath-filter" : ["p2/c2" , "p3/c3"]
        }
    ]
    }


  2. We now look at the "ActiveSubscriptions"  if we already have an active subscription either for a combination of "cmhandle and xpath filter and the datastore".

    Current view of ActiveSubscriptions

    SubscriptionId

    cmHandle

    filter

    datastore

    A-10ch-1p1/c1ncmp-datastore:passthrough-operational
    A-10ch-1p2/c2ncmp-datastore:passthrough-operational
    A-10ch-2p1/c1ncmp-datastore:passthrough-operational
    A-10ch-2p2/c2ncmp-datastore:passthrough-operational

    Check if we have ch-2 , p2/c2 and ncmp-datastore:passthrough-operational then directly add to the ActiveSubscription. Similarly check for ch-3 , p3/c3 and ncmp-datastore:passthrough-operational ( which in this case will not be directly to the active subscription)


  3. Now the state of ActiveSubscription is :

    SubscriptionId

    cmHandle

    filter

    datastore

    A-10ch-1p1/c1ncmp-datastore:passthrough-operational
    A-10ch-1p2/c2ncmp-datastore:passthrough-operational
    A-10ch-2p1/c1ncmp-datastore:passthrough-operational
    A-10ch-2p2/c2ncmp-datastore:passthrough-operational
    B-52ch-2p2/c2ncmp-datastore:passthrough-operational

    and state of the in-memory data structure is as follows.

    SubscriptionId

    dmi-plugin

    affectedCmHandles

    status

    B-52dmi-1["ch-2"]PENDING


  4. Now we send the request to DMI plugin (dmi-1) with just the private properties of the ch-2 with the delta xpath.
    1. DMI Plugin could either apply the whole subscription request or reject the whole subscription. i.e respond with accepted/rejected
  5. Based on the response from DMI plugin the in-memory structure is updated and response is sent back to the clients.

    if DMI says it is accepted then : 

    SubscriptionId

    dmi-plugin

    affectedCmHandles

    status

    B-52dmi-1["ch-2"]ACCEPTED


    if DMI says it is rejected then : 

    SubscriptionId

    dmi-plugin

    affectedCmHandles

    status

    B-52dmi-1["ch-2"]REJECTED


    if we get no response within the configured time then :

    SubscriptionId

    dmi-plugin

    affectedCmHandles

    status

    B-52dmi-1["ch-2"]PENDING


    But we still send some response within the pre-configured time.


  6. if the above request was accepted then we should add it to the list of "ActiveSubscriptions" as well.

    SubscriptionId

    cmHandle

    filter

    datastore

    A-10ch-1p1/c1ncmp-datastore:passthrough-operational
    A-10ch-1p2/c2ncmp-datastore:passthrough-operational
    A-10ch-2p1/c1ncmp-datastore:passthrough-operational
    A-10ch-2p2/c2ncmp-datastore:passthrough-operational
    B-52ch-2p2/c2ncmp-datastore:passthrough-operational
    B-52ch-2p3/c3ncmp-datastore:passthrough-operational


  7. If the status was accepted/rejected then after sending the response to the client we can clear the in-memory structure for subscriptionId B-52.

...