...
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 dont 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) | kieran mccarthy re-use existing LCM event → also send it on topic for he subscription (currently fixed) Note. need to add subscription if (name+client id) to header | ||||
| 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 mccarthyconfirm DMI can reject whole subscrptionsubscription | ||||
| 7 | implementation question: should 'rejected' DMI-subscriptions be stored | not needed as whole subscription should be rejected | kieran mccarthyconfirm | ||||
| 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 | |||||
| 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! | 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 | ||||
| 11 | can the same cm handle/xpath have different subscriptions with different datastores, does that affect the cm data notifications send (which datastore applies) | ||||||
| 12 | willWill 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 | *Might
| yes, from NCMP point of view a list and a list entry are different xpaths | |||
| 14 | confirm subscription id (currently name + client id) | kieran mccarthy to clarify ASAP | |||||
| 15 | what subscription details should be send when | theerthere is a change (in | thenthe union) |
| (after initial meeting) kieran mccarthy & Toine Siebelink agreed that because of the possible size of | data (200 * 10 entries) the union (200x200x10=400,000) it is only feasible to send the delta ie option 1. |
Solution Proposals
Current state handling for 'basic' (not merged) subscription create/delete (under development)
...
| draw.io Diagram | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Create Combinations
Below examples demonstrate what should happen when two separate subscriptions operations are performed:
...
| # | Existing Subscription A-10 | Client Create Subscription B-52 Request | DMI Sub Create Request (union if changed) | Data Model Before (2nd) Create | Data Model After Create | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | CH-1, [ /p/c1, /p/c2 ] | CH-1, [ /p/c1 ] | None |
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2 | CH-1, [ /p/c1, p/c2 ] | CH-1, [ /p/c2, /p/c3 ] | CH-1, [ /p/c2, /p/c3 ] |
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 3 | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-2, [ /p/c1] CH-3, [ /p/c1]Union | CH-1, [ /p/c1] CH-2, [ /p/c1] Added CH-3, [ /p/c1] |
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 4 | CH-1, [ /p/c1] | CH-1, [ /p/c1/gc1 ] | CH-1, [ /p/c1 /gc1 ] (see issue #1)/gc1 ] *as per decision 1 the xpath to a parent does NOT include any children... |
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
...
| # | Existing Subscription A-10 | Existing Subscription B-52 | Client Delete A-10 Request | DMI UpdateSub update/delete request | Data Model Before Before | Data Model After Delete | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | CH-1, [ /p/c1, p/c2 ] | CH-1, [ /p/c1 ] | CH-1, [ p/c2 ] |
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 2 | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-2, [ /p/c1] CH-3, [ /p/c1]Union | CH-2 [ /p/c1] |
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 3 | CH-1, [ /p/c1] | CH-1, [ /p/c1] CH-2, [ /p/c1] | None |
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
...
| Previous Interaction | Current Interaction | Expectation | Notes | |
|---|---|---|---|---|
| 1 | any operation on rejected for non-existing cm-handle | operation for same non-existing cm-handle | listed in 'rejected' immediately | behavior as normal |
| 2 | create operation rejected by DMI | create for same cm-handle/xpath | try again ?! | |
| 3 | create pending | create for same cm-handle/xpath | TBD send again or just remain pending?! | |
| 4 | create pending | delete for same cm-handle/xpath | ||
| 5 | delete pending | delete for same cm-handle/xpathalso being considered for 'basic' delete | ||
| 6 | delete pending | create for same cm-handle/xpathalso being considered for 'basic' delete | ||
| 7 |
Performance considerations
...