- CPS-1812Getting issue details... STATUS
Requirements
Functional
# | Interface | Requirement | Additional Information | Sign Off |
---|---|---|---|---|
1 | CPS-E-08.e | NCMP is to merge CM Notification Subscriptions Create request for the same CM Handle & XPath(s) |
| |
2 | CPS-E-08.e | Last lights out: upon subscription Delete request only when there is no more subscription for a cm-handle & xpath combination a subscription-delete request wil be send to the relevant DMI(s) | ||
3 | CPS-E-08.e | Amalgamation per DMI: all subscription updates originating from a single client request should be send to a single DMI in one request (message). Of course there can be several message if more than 1 DMI is involved. | ||
4 | CPS-NCMP-I-01 | CM Handle deletion should update subscription details | do NOT delete dmi-subscription entry until owning subscription is deleted, see issue #4 below | |
5 | CPS-E-08.e | backward compatible with 'basic' created/delete operations.. TBD | could use versioning in API–methods and schema's to handle this?! |
Error Handling
Error Scenario | Expected behavior | Sign-off | |
---|---|---|---|
1 | DMI Down | rejected | |
2 | DMI Not responding withing 30 sec | pending | |
3 | create for non-existing cm handle id | rejected | |
4 | delete for non-existing cm handle id | (silently?) ignore | |
5 | any operation on non-existing xpath | ignore? (no or minimal validation, see issue #5) | |
6 | delete for non existing name/client-id | TBD, should be handle in 'basic' solution | |
7 | delete for no existing cm-handle id | ignore? (no or minimal validation, see issue #5) | |
8 | error upon error | An error scenario on a second subscription for the same cm-handle/xpath as a previous subscription which did not complete successfully (yet) to be discussed, see tabel below |
Characteristics
# | Parameter | Expectation | Notes |
---|---|---|---|
1 | Maximum number of cm data subscriptions | ||
2 | Maximum, Average CM Handles/subscription | ||
3 | Maximum, Average XPaths/CmHandles | ||
4 | Status update processing time limit | Based on the numbers above working out the current state of each cm handle/xpath combination could be slow! | |
5 |
Out-of-scope
- CM Notification Forwarding Check: When forwarding CM Notification NCMP will not check the content to see if the is a valid active subscription. It is assumed that the DMI Plugin as acted on the 'delete subscription' request (that request is NCMPs responsibility). And of course there wil be timing issues it also possible a CM Notification was send just after the subscription-delete was send (from client) but before the whole change had acted upon that.
- Retry: NCMP wil only report when actions are pending or rejected. NCMP will not implement a retry mechanism
- Wildcards: Wildcards or similar functionality where one string represent 0 or more xpaths is not covered as part of this requirement but it should be kept in mind as a future possibility
- Dynamic Topic: Topic for CM Data Notifications back to client will be hardcode for now
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:
| |
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 (assume no) | do NOT delete dmi-subscription entry until owning subscription is deleted (just ignore upon future delete if cm handle is gone altogether) | |
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 | I would think not | |
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 | |
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-Handled have different set of xpaths(s) per subscription | teh 'basic' solution only supports a common set of daatstore/xpaths (filter) |
Solution Proposals
Current state handling for 'basic' (not merged) subscription create/delete (under development)
Note. The above algorithm depends ons storing (in DB using yang modelled data) a cm-handle status for each cm-handle for each subscription!
Merge → Split
- NCMP treats a Client Subscription as one or more (small) DMI Subscriptions, each of which wil have there own state.
Each DMI Subscription is related to 1 or more client subscriptions.
If there is no more related client subscription the DMI Subscription can be deleted (once accepted by DMI Plugin)!
Data Model (not a great diagram...)
Create Combinations
Existing Subscription A-10 | Client Create Subscription B-52 Request | DMI Create Request | Data Model Before | Data Model After | |
---|---|---|---|---|---|
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/c3 ] | ||
3 | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-2, [ /p/c1] CH-3, [ /p/c1] | CH-3, [ /p/c1] | ||
4 | CH-1, [ /p/c1] | CH-1, [ /p/c1/gc1 ] | CH-1, [ /p/c1/gc1 ] (see issue #1) |
Delete Combinations
NCMP Existing A | NCMP Existing B | Client Delete A Request | DMI Delete Request | |
---|---|---|---|---|
1 | CH-1, [ /p/c1, p/c2 ] | CH-1, [ /p/c1 ] | CH-1, [ /p/c1, p/c2 ] | CH-1, [ p/c2 ] |
2 | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-2, [ /p/c1] CH-3, [ /p/c1] | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-1, [ /p/c1] |
3 | CH-1, [ /p/c1] | CH-1, [ /p/c1] CH-2, [ /p/c1] | CH-1, [ /p/c1] | None |
Error-Upon-Error Combinations
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/xpath | also being considered for 'basic' delete | |
6 | delete pending | create for same cm-handle/xpath | also being considered for 'basic' delete | |
7 |
Performance considerations
- DMI record could reach in millions of instances
- In memory solution (ie hazelcast) can handle 10s - 100s of Megabytes (add some sample calc)
- still need persistence if we don't have enough intsances
- use many small messages reduce need for amalgamation
- amalgamated string-based solution....
Proposed JIRAs
Priority | Component | Description | JIRA | Estimates |
---|---|---|---|---|
1 | ||||
2 | ||||
3 | ||||
4 | ||||
5 | ||||
6 | ||||
7 | ||||
8 |