...
Assumptions
# | Assumption | Notes |
---|---|---|
1 | Targets is a collection of xpaths | can be implemented as a json array of strings |
2 | for the DMI plugin cm-handle-id and xpath are the key to a unique subscription | the 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
Issue | Notes | Decision | |
---|---|---|---|
1 | Is 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:
| kieran mccarthy descendant not covered by 'basic' paths Wildcard will cover this kind of function in future |
2 | Could 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) |
3 | Should NCMP support re-homing, moving of a CM Handle from one DMI to another? | assume only trough delete & create | kieran mccarthy out of scope |
4 | CM Handle Delete: Should DMI or Clients be sent a subscription update | do NOT delete dmi-subscription entry until owning subscription is deleted Note. LCM is already broadcast (today) |
|
5 | Validation of xpath | options order of implement and also performance cost!
| kieran mccarthy not required right now |
6 | can 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... | 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 |
7 | implementation question: should 'rejected' DMI-subscriptions be stored | not needed as whole subscription should be rejected | kieran mccarthyconfirms |
8 | Dimensioning 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! |
9 | Maximum (error) message size | theoretically 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 |
10 | can each CM-Handle have different set of xpath(s) per subscription | the 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) |
11 | can the same cm handle/xpath have different subscriptions with different datastores, does that affect the cm data notifications send (which datastore applies) |
| 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. |
12 | Will migration from 'basic' be supported | Preferred to ask customers to create new subscriptions | kieran mccarthy no need to support (migration) of 'basic' solution. Development of 'basic' solution can be stopped! |
13 | list v list instances filtering | /p/c1 | kieran mccarthy yes, from NCMP point of view a list and a list entry are different xpaths |
14 | confirm subscription id (currently subscription name + client id) | kieran mccarthy to clarify ASAP including exact format all prefer a single id-field | |
15 | what subscription details should be send when there is a change (in the union) |
| (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. |
16 | one 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' |
...
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"] } ] }
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 ActiveSubscriptionsSubscriptionId cmHandle filter datastore A-10 ch-1 p1/c1 ncmp-datastore:passthrough-operational A-10 ch-1 p2/c2 ncmp-datastore:passthrough-operational A-10 ch-2 p1/c1 ncmp-datastore:passthrough-operational A-10 ch-2 p2/c2 ncmp-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)Now the state of ActiveSubscription is :
SubscriptionId cmHandle filter datastore A-10 ch-1 p1/c1 ncmp-datastore:passthrough-operational A-10 ch-1 p2/c2 ncmp-datastore:passthrough-operational A-10 ch-2 p1/c1 ncmp-datastore:passthrough-operational A-10 ch-2 p2/c2 ncmp-datastore:passthrough-operational B-52 ch-2 p2/c2 ncmp-datastore:passthrough-operational and state of the in-memory datastructure is as follows.
SubscriptionId dmi-plugin affectedCmHandles status B-52 dmi-1 ["ch-2"] PENDING - Now we send the request to DMI plugin (dmi-1) with just the private properties of the ch-2 with the delta xpath.
- DMI Plugin could either apply the whole subscription request or reject the whole subscription. i.e respond with accepted/rejected
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-52 dmi-1 ["ch-2"] ACCEPTED
if DMI says it is rejected then :SubscriptionId dmi-plugin affectedCmHandles status B-52 dmi-1 ["ch-2"] REJECTED
if we get no response within the configured time then :SubscriptionId dmi-plugin affectedCmHandles status B-52 dmi-1 ["ch-2"] PENDING
But we still send some response within the pre-configured time.- 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.
...