References
- Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
- Impl. Proposal CM Subscriptions : Creating/Merging( Positive Scenarios )
Requirements
Functional
Interface | Requirement | Additional Information | Signoff | |
|---|---|---|---|---|
| 1 | CPS-E-08e | NCMP will forward 'CM Notifications Subscription' LCM Create events to the appropriate DMI Plugins responsible for the CM Handles (ids) defined in the LCM Events. The message sent to DMI should include the private properties for each CM-Handle |
| |
| 2 | CPS-E-08e | NCMP will forward 'CM Notifications Subscription' LCM Delete events to the appropriate DMI Plugins responsible for the CM Handles is defined in the LCM Events. A delete should only be forwarded if there is no other subscription for cmhandle datastore path. |
| |
| 3 | CPS-E-08e | NCMP responds using Kafka message(s) with the result of the LCM operation These messages will use agreed status fields:
| Action: Define error details later | |
| 4 | CPS-E-08e | All events should use Cloud Events format | https://cloudevents.io/ | |
| 5 | CPS-E-08e | Messages should be processed in the order they are created (received) | It will depend on DMIs responding within 30s. Subscription-id should be used as Kafka 'key' to ensure this. | |
| 6 | CPS-E-08.e | NCMP is to merge CM Notification Subscriptions create request and forward those to DMI plugin. (Interface to be added). |
| |
| 7 | CPS-E-08.e | Last lights out: upon subscription Delete request only when there is no more subscription for a cm-handle & xpath & datastore combination a subscription-delete request will be sent to the relevant DMI(s). | ||
| 8 | CPS-E-08.e | A single client subscription request should result into a maximum of one request per DMI. Of course there can be several messages if more than 1 DMI is involved. | ||
| 9 | CPS-E-08.e | Amalgamate response should include rejected/accepted/pending DMI responses received within 30 seconds. A client shall be notified of available DMI subscription information after 30 seconds. Subsequent DMI subscription updates shall be notified to clients as they become available. |
| |
| 10 | CPS-NCMP-I-01 | CM Handle deletion should NOT update subscription details. | Do NOT delete dmi-subscription entry until owning subscription is deleted, see issue #4 below | |
| 11 | CPS-E-08.e |
Error Handling
Error Scenario | Expected behavior | Sign-off | |
|---|---|---|---|
| 1 | Non responding DMIs (configurable timeout) | An error message listing the 'pending' CM Handle IDs. statusMessage/statusCode to be agreed. | |
| 2 | Non Existing or non-valid CM Handle Ids | An error message listing the 'rejected' CM Handle IDs. | |
| 3 | DMI Plugin without CM Event subscription support | An error message listing the 'rejected' CM Handle IDs | |
| 4 | Late Response (after timeout defined in #1) from DMI | A list of outcomes (complete status on how many cmhandles are pending/rejected/accepted) from client subscription is returned in response. statusMessage/statusCode to be agreed. |
|
| 5 | Create for existing subscription id | The whole subscription will be rejected. statusMessage/statusCode to be agreed. |
|
| 6 | Delete for non-existing subscription id | The whole delete subscription will be rejected. statusMessage/statusCode to be agreed. |
|
| 7 | 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 Error Upon Error Combinations |
Characteristics
Parameter | Expectation | Notes | Sign-off | |
|---|---|---|---|---|
| 1 | Frequency of LCM Subscription Events | No high volume of such events is expected For testing purpose 1 LCM event per minute would suffice. | kieran mccarthy confirmed |
|
| 2 | Number of Subscriptions | Max: 200 | kieran mccarthy confirmed | |
| 3 | CM Handles per Subscription | Avg: 200 Max: 500 (document only) | kieran mccarthy to confirm | |
| 4 | Xpaths per Cm Handle | Avg: 10 | ||
| 5 | Status update processing time | (Order of 30) seconds (NCMP side) |
Out-of-scope
- Subscription Update scenarios for an ongoing subscription.
- 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 will 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.
Study should consider compatibility with an 'ALL' cm handles options - The proposed Schema Change & HTTP Rest (reate DME subscription interfaces as a new subscriotion epic) has led to new epic which will be implemented in → -[CPS-2233] CM Subscription with DME interface - ONAP Jira
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, datastore 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:
| Descendent don't need to be taken into account |
| 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? | xpath can point to an element that does not exist (yet) CPS/NCMP Does not need to check Xpath |
| 3 | Should NCMP support re-homing, moving of a CM Handle from one DMI to another? | assume only trough delete & create | 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) | No, subscription update
|
| 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 | 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! | ?? what was agreed ? Kolawole Adebisi-Adeolokun to update what was agree |
| 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) | Yes, schema modification allows this |
| 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 | No, basic sub. will not be delivered as a separate feature |
| 13 | list v list instances filtering | /p/c1 | List entries are unique. |
| 14 | confirm subscription id (currently subscription name + client id) | previously was clientid and subcrioptionid and we were relying on concatenation of both to be unique | Now only the event would contain subcrioptionid |
| 15 | what subscription details should be send when there is a change (in the union) |
| Just Delta |
| 16 | one DMI rejects whole (see decision #6) subscription (affected cmhandles) but other DMI accepts the same subscription, is this possible how to handle | Yes, this has been analysed | |
| 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? | 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. | subscriptionId to be used. |
| 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 ? | Yes, reuse. | kieran mccarthy - Reuse the same codes defined in NCMP. |
| 20 | Impl. Proposal for Merging of Subscription | Schemas Agreed for the below events ( Source to Destination ) for the positive scenarios.
| |
| 21 | Create DME subscription interfaces Schema Change | Schema Change, Events driven change now HTTP Rest. Study status is at 2/3 of review. CPS need to study new changes to subscription once study is approved. | New Subscription changes forecasted for 25Q2. Create DME subscription interfaces as a new subscription epic -[CPS-2233] CM Subscription with DME interface - ONAP Jira
Kolawole Adebisi-Adeolokun to create backlog Jira |
Solution Proposal
State handling for initial (basic)subscription create/delete use cases (not using concept of 'merging')
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
Below examples demonstrate what should happen when two separate subscriptions operations are performed:
- an operation on subscription 'A' for client id '10
- an operation on subscription 'B' for client id '52'
| # | Existing Subscription A-10 | Client Create Subscription B-52 Request | DMI Sub Create Request | 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] | CH-3, [ /p/c1] | ||
| 4 | CH-1, [ /p/c1] | CH-1, [ /p/c1/gc1 ] | CH-1, [ /p/c1/gc1 ] *as per decision 1 the xpath to a parent does NOT include any children... |
Create 'Merge' Diagram
Below diagram shows and example for two subscriptions with party overlapping CM Handles and XPaths.
* Note 1: given the possible combinations the message to DMI needs to be able to specify different xpaths per cm-handle. So a more complex structure is needed for this even ie. an array of CM Handles objects each having their own list of (target) xpaths!
Note 2: as per decision #11'datastore' should be included in all messages as well
Note 3: the correlation-id for message to and from to DMI will be composed from the subscription-id and the dmi-name
Delete Combinations
| # | Existing Subscription A-10 | Existing Subscription B-52 | Client Delete A-10 Request | DMI Sub 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] | CH-1, [ /p/c1] | |||
| 3 | CH-1, [ /p/c1] | CH-1, [ /p/c1] CH-2, [ /p/c1] | None |
* Note: as per decision #11'datastore' should be included in the 'DMI susbcription' data model too now.
Error-Upon-Error Combinations
( To be captured as part of )
| 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/Busy' | up to client to retry the operation. |
|
| 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/Busy' | up to client to retry the operation. |
|
Client-Schema Update
Based on Issue#10 , the incoming schema from DME to NCMP should
- A single subscription contains multiple predicates
- Predicates should be an array of Predicates ( currently a single instance )
- Each predicate contains an array of targets ( cmhandles) - as is.
- Each predicate contains a single datastore (mandatory)
- datastore-xpath-filter should become an array of xpath-filters (instead of pipe separated single string)
Performance considerations
Below options (partly) explored dring CPS teem meeting
- 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 instances
- use many small messages reduce need for amalgamation
- amalgamated string-based solution....
Kafka Topics
| # | Topic Name | Environment Variable | Source | Destination | Notes |
|---|---|---|---|---|---|
| 1 | subscription | CM_SUBSCRIPTION_NCMP_IN_TOPIC | DME | DME/Client-Apps | |
| 2 | ncmp-dmi-cm-avc-subscription | CM_SUBSCRIPTION_DMI_IN_TOPIC | NCMP | DMI Plugin | |
| 3 | dmi-ncmp-cm-avc-subscription | CM_SUBSCRIPTION_DMI_OUT_TOPIC | DMI Plugin | NCMP | |
| 4 | subscription-response | CM_SUBSCRIPTION_NCMP_OUT_TOPIC | NCMP | DME/Client-Apps | |
| 5 | dmi-cm-events | DMI_CM_EVENTS_TOPIC | DMI Plugin | NCMP | actual data notifications as per the subscriptions |
| 6 | cm-events | NCMP_CM_EVENTS_TOPIC | NCMP | DME/Client-Apps | NCMP to forward the notifications to the client-apps. |