...
Assumptions
# | Issue | Notes | Decisions |
---|---|---|---|
1 | The whole subscription event is deletedDelete use case works for a valid ongoing subscription only. | ||
2 | Works only for the passthrough datastores. |
Issues & Decisions
# | Issue | Notes | Decisions |
---|---|---|---|
1 | Delete the subscription from the database? |
| |
2 | What do we need to send to the DMI Plugin so that they are able to decide that how to delete the ongoing subscription. |
| |
3 | The subscription delete request should be able to retry and make sure the subscriptions are deleted from the respective DMIs managing the devices. | kieran mccarthy The agenda for the next meeting. We can decide then. More on the "DELETING" stage ( if we want to have it ) | kieran mccarthy As discussed on , The DME should be able to maintain Subscription State and make decision when to retry based on the response outcome we provide to it for create and/or delete use cases. |
4 | DME to NCMP Event to have targets and datastore-xpath-filter information for the subscription delete use case ? | kieran mccarthy As per the discussion today we agreed to use targets , datastore-xpath-filters and datastores for the subscription delete use case. |
Overview
- We receive an event of type : subscriptionDeleted from the client ( DME ) containing the subscription clientId and subscription name along with datastore and dataCategory details ( DMEtoNCMP )
- We check in NCMP that we have an ongoing subscription using clientId and subscriptionName.
- If we have ongoing subscription , we forward the event to dmi-plugins so that the changes are applied in the devices managed by dmi-plugin as well. ( Impl. Proposal CM Event Subscription LCM: Delete )
- Now if the dmi-plugins have applied the request then we get an event back from dmi-plugin and NCMP will process that event and based on that it will delete the ongoing subscription request from the database itself. If the response from DMI plugins is accepted ( i.e it can delete the subscriptions from the underlying devices and no subscription delete request are in PENDING or REJECTED state )Then we delete the subscriptions from the DB as well. ( Impl. Proposal CM Event Subscription LCM: Delete )
- After processing the received event from DMI , NCMP will send the final event to the client (DME). ( Impl. Proposal CM Event Subscription LCM: Delete )
...
|
...
|
DB Logic for subscription delete handling
- NCMP receives subscription delete response from DMI Plugins
- If all DMIs have responded within 30 seconds:
- delete subscription from db and send subscription delete accepted response to client
- If some DMIs respond within 30 seconds
- update subscription with pending for the DMIs which have not responded, for the DMIs which have responded, remove those CMHandles from the subscription db
- send response to clients
- wait for DMIs to respond, update db according to DMI response and respond to client
- If all DMIs respond but some are rejected,
- remove dmis which have been accepted and mark rest as rejected.
- send response to clients