Versions Compared

Old Version 46

changes.mady.by.user Priyank Maheshwari

Saved on

compared with

New Version 47

changes.mady.by.user Priyank Maheshwari

Saved on

Key

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

...

Assumptions

#AssumptionNotes
1Targets is a collection of xpathscan be implemented as a json array of strings
2for the DMI plugin cm-handle-id and xpath are the key to a unique subscriptionthe client-id and subscription name are not relevant for the DMI (should not be included in the request) as this would break the concept of merging!

Issues & Decisions


IssueNotes Decision
1Is it intended that CM Notification subscription request  cover (all) descendants of the given xpath too?!e.g.. if a child is removed and there is a subscription for the parent node, will a notification be send (grandchild, child leaf updates etc.) I hope NOT!
Consider:
  • Risk of client effectively subscribing to ALL data in a cm handle by specifying top level datanode(s)
  • Complexity (i.e. cost of) of merge operation. It might even required NCMP to check relevant dat model
  • Future use of wildcards, could be a viable alternative for including descendants

kieran mccarthy descendant not covered by 'basic' paths Wildcard will cover this kind of function in future 

2Could xpath point to an element that does not exist (yet)if not how, how can I client be informed about a create event? 

kieran mccarthy  yes, xpath can point to things that don't exist yet (not even in the curernt model when an upgraded is pending)

3Should NCMP support re-homing, moving of a CM Handle from one DMI to another?assume only trough delete & create 

kieran mccarthy out of scope 

4CM Handle Delete: Should DMI or Clients be sent a subscription update 

do NOT delete dmi-subscription entry until owning subscription is deleted
(just ignore upon future delete if cm handle is gone altogether)

Note. LCM is already broadcast (today) 


  • kieran mccarthy re-use existing LCM event → also send it on topic for he subscription (currently fixed topic)
  • Need to upgrade to CloudEevent format
  • Add subscription id (name+client id) to header (so client can filter)
5Validation of xpathoptions order of implement and also performance cost!
  1. none
  2. xpath-parser
  3. model check
  4. instance check

kieran mccarthy not required right now 

6can DMI plugin 'reject' a subscription create (for a given cm-handle-xpath combination)As NCMP might not validate as per issue#5 the DMI=plugin or component further down might have to reject an invalid xpath...

Priyank Maheshwari 

yes currently DMI can use response to say which cm handles are not accepted i.e. rejected' (but not 'pending') 

kieran mccarthyconfirms DMI can reject whole subscription

7implementation question: should 'rejected' DMI-subscriptions be storednot needed as whole subscription should be rejected

kieran mccarthyconfirms

8Dimensioning of DB depends on #cm handles, #subscriptions and #xpaths per subscription, this could be too big for fast processing of updates! Need to agree maximum and possibly realistic average/total number of entries based on the characteristics  above
The team is blocked until this becomes clear as it wil affect the way the data needs to be modelled exactly		ongoing but not completed!
9Maximum (error) message sizetheoretically all cm handles and all xpaths combinations could be rejected or pending leading to a very large error message!

Toine Siebelink no longer relevant given and max decided 

10can each CM-Handle have different set of xpath(s) per subscriptionthe  current 'basic' solution only supports a common set of datastore/xpaths (filter)

 kieran mccarthy Yes, clients will create only one subscription and they might have different needs for different nodes (cm handles) 

11can the same cm handle/xpath have different subscriptions with different datastores, does that affect the cm data notifications send (which datastore applies)
  • can register on any (passthrough) datastore
    • running
    • operational

  • compulsory, validation needed
  • part of KEY (unique entry) so cmHandle+datastore+xpath is the key 


kieran mccarthy datastore included.

Although this wiki-page will not be updated where cmHandle+xpath is mentioned as  unique entry etc. this should now include a third field: datastore as well.

12Will migration from 'basic' be supportedPreferred to ask customers to create new subscriptions

kieran mccarthy no need to support (migration) of 'basic' solution. Development of 'basic' solution can be stopped!

13list v list instances filtering

/p/c1
/p/c1[@key=23]
Are these different paths or not (from ncmp point of view)
*List instances might not always be supported, depending DMI Plugin impl.

kieran mccarthy yes, from NCMP point of view a list and a list entry are different xpaths

14confirm subscription id (currently subscription name + client id)

kieran mccarthy to clarify ASAP including exact format

all prefer a single id-field


15what subscription details should be send when there is a change (in the union)
  1. just delta
  2. just union
  3. union and delta (delta flagged) 

(after initial meeting) kieran mccarthy & Toine Siebelink  agreed that because of the possible size of the union (200x200x10=400,000) it is only feasible to send the delta ie option 1.

16one DMI rejects whole (see decision #6) subscription (affected cmhandles) but other DMI accepts the same subscription, is this possible how to handle

kieran mccarthy only sends message back to client about rejected DMIs i.e. the subscription can be partially 'active'

...

  1. We get a new subscription create request.

    Code Block
    {
"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

    SubscriptionIdcmHandlefilterdatastore
    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 :

    SubscriptionIdcmHandlefilterdatastore
    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 datastructure is as follows.

    SubscriptionIddmi-pluginaffectedCmHandlesstatus
    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 : 

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


    if DMI says it is rejected then : 

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


    if we get no response within the configured time then :


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


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

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

...