References
- CPS-1616 - Getting issue details... STATUS
- CPS-1615 - Getting issue details... STATUS
- CPS-1812 - Getting issue details... STATUS
- Impl. Proposal CM Event Subscription LCM: Create
- Impl. Proposal CM Event Subscription LCM: Delete
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. The message sent to DMI should include the private properties for each CM-Handle | 'Basic' delete we be implemented followed by a more advanced delete operation depending on Merge functionality: CPS-1812 - Getting issue details... STATUS | |
| 3 | CPS-E-08e | NCMP responds using Kafka message(s) with the result of the LCM operation These messages wil 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). |
| kieran mccarthy |
| 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 | LCM and Merge-functionality are now closely interlinked and no separate delivery f LCM without merging support wil be done |
Error Handling
Error Scenario | Expected behavior | Sign-off |
|---|---|---|
| Non responding DMIs (configurable timeout) | An error message listing the 'pending' CM Handle IDs and statusMessage as "partially applied subscription" with relevant statuscode. | |
| Non Existing or non-valid CM Handle Ids | An error message listing the 'rejected' CM Handle IDs | |
| DMI Plugin without CM Event subscription support | An error message listing the 'rejected' CM Handle IDs | |
| Late Response (after timeout defined in #1) from DMI | A message contain the status message as "fully applied subscription" with relevant status code. | |
| delete for non-existing cm handle id | (silently?) ignore | |
| delete for non existing subscription id | ||
| 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 | Frequency of LCM Events | No high volume of such events is expected For testing purposed 1 LCM event per minute would suffice |
Out-of-scope
- Working with the wildcards, only list of specific CM Handle IDs are supported
- Subscription Update scenarios for an ongoing subscription.
Assumptions
# | Assumption | Notes |
|---|---|---|
| 1 | Developing based on the schemas we previously agreed. Any change in the schemas will impact in code change. |
Issues & Decisions
# | Issue | Notes | Decision |
|---|---|---|---|
| 1 | Maximum number of cm data subscriptions for create and delete use case | ||
| 2 | Maximum, Average CM Handles/subscription | ||
| 3 | Maximum, Average XPaths/CmHandles | ||
| 4 | What all datastores are supported ? | ncmp-datastore:passthrough-running or ncmp-datastore:passthrough-operational ?? or both? | |
| 5 | Will migration to new 'advanced' subscriptions (with merge function) be supported | wil be costly. Or required model update BEFORE the basic subscription functionality is delivered |
Overview
- Page to keep track of the underlying use case for Subscription Create and Subscription Delete.
- The events used will adhere to CNCF Cloud Events.
- NCMP wil not be responsible for keeping the 'state' of any subscription and thus decide which CM Events should be forwarded
Kafka Topics
| # | Topic Name | Environment Variable | Source | Destination | Notes |
|---|---|---|---|---|---|
| 1 | subscription | NCMP_CM_AVC_SUBSCRIPTION | DME | DME/Client-Apps | |
| 2 | ncmp-dmi-cm-avc-subscription-<dmi-name> | NCMP_FORWARD_CM_AVC_SUBSCRIPTION | NCMP | DMI Plugin | |
| 3 | dmi-ncmp-cm-avc-subscription | NCMP_RESPONSE_CM_AVC_SUBSCRIPTION | DMI Plugin | NCMP | |
| 4 | subscription-response | NCMP_OUTCOME_CM_AVC_SUBSCRIPTION | 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. |