...
| 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:
| |
| 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? | |
| 3 | Should NCMP support re-homing, moving of a CM Handle from one DMI to another? | assume only trough delete & create | |
| 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!
| |
| 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') |
| 7 | implementation question: should 'rejected' DMI-subscriptions be stored | not needed as whole subscription should be rejected | |
| 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 | - kieran mccarthy- Dimensioning has been agreed. See Characteristics |
| 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! | |
| 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) | |
| 11 | can the same cm handle/xpath have different subscriptions with different datastores, does that affect the cm data notifications send (which datastore applies) |
| 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 | |
| 13 | list v list instances filtering | /p/c1 | |
| 14 | confirm subscription id (currently subscription name + client id) | ||
| 15 | what subscription details should be send when there is a change (in the union) |
| |
| 16 | one DMI rejects whole (see decision #6) subscription (affected cmhandles) but other DMI accepts the same subscription, is this possible how to handle | ||
| 17 | What all datastores are supported ? | ncmp-datastore:passthrough-running or ncmp-datastore:passthrough-operational ?? or both? | - kieran mccarthy Both will be supported |
| 18 | When NCMP sends subscription request to DMI and then DMI responds back to NCMP , do we need to have a correlationId to track/map the request and response? | subscriptionId to be used. Value: subscriptionID:DMIPluginName (Check if subscriptionId or DMIPlugin name doesn't contain a colon: ) - The seperator is to be chosen by the development team, will try with colon first. |
|
| 19 | Which status codes to be used when the DMI Plugins respond back to NCMP ? We already have codes defined in NCMP. Do we reuse the same status codes when DMI Plugin responds back to NCMP with the subscription status ? |
Solution Proposal
...
Yes, reuse. | kieran mccarthy - Reuse the same codes defined in NCMP. |
Solution Proposal
State handling for initial (basic)subscription create/delete use cases (not using concept of 'merging')
...
Error-Upon-Error Combinations
| Previous Interaction | Current Interaction | Expectation | Notes | Sign-Off | |
|---|---|---|---|---|---|
| 1 | any operation on |
| 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 |
| Submit create request again. |
| |
| 3 | create pending | create for same cm-handle/xpath |
| Set it to pending without submitting a new request. When we get response for previous interaction it is applied for the current interaction as well. |
| ||||
| 4 | create pending | delete for same cm-handle/xpath | Set an error 'Conflict/Retry' |
| |
| 5 | delete pending | delete for same cm-handle/xpath | Set it to pending without submitting a new request. When we get response for previous interaction it is applied for the current interaction as well. |
| |
| 6 | delete pending | create for same cm-handle/xpath | Set an error 'Conflict/Retry' - up to client to retry the create operation. |
|
Client-Schema Update
Based on Issue#10 , the incoming schema from DME to NCMP should
...