| Table of Contents |
|---|
Overview
...
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
- Each Cm-Handle state change triggers a LCM event notification sent to the user to notify about the state change.
- When a cm handle Cm-Handle is registered it will initially be set in an 'ADVISED' state and .
- If the module sync watchdog operation starts to work on an 'ADVISED' Cm-Handle, the Cm-Handle state will transition to 'READY' or 'LOCKED' based on if the module-sync has succeeded or failed respectively.
- If the module sync watchdog operation is successful, data-sync-enabled will be set to false by and the module-sync watchdogdata sync-state will be 'NONE_REQUESTED'.
- If the user wants to enable set data-sync- enabled to true, it has to enable it be enabled on its dedicated API endpoint.
- Once data sync-enabled is set to true, the data sync-state will be set to 'UNSYNCHRONIZED'.
- Only the handles with enabled an 'UNSYNCHRONIZED' data sync-sync state will be picked up by the data-sync watchdog operation.
- If the data-sync watchdog was able to complete the sync successfully then the dataStoreSync state will changed to SYNCHRONIZED.
- If the handles are to be deleted during update, then their states will be set to 'DELETING' before the deletion happens, then after it to 'DELETED'
- If the data-sync watchdog starts to work with on a cm Handle state transitions to 'READY' or 'LOCKED' whether data-sync succeeded or failed respectively
- If the data-sync watchdog was able to the sync then the dataStoreSync state will changed to SYNCHRONIZED
- . Once deletion is complete, the state is set to 'DELETED'.
Diagram of the possible transactions between CM-Handle states
| Insert excerpt | ||||
|---|---|---|---|---|
|
...
Notification handling in code
| Inc drawiogliffy | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The Event structure of the notification
...
| Gliffy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
State changes after cm Handle update received
| Gliffy | ||||||
|---|---|---|---|---|---|---|
|
State changes
...
during
...
module-sync watchdog execution
| Gliffy | ||||||
|---|---|---|---|---|---|---|
|
State changes during data-sync watchdog execution
| Gliffy | ||||||
|---|---|---|---|---|---|---|
|
Source materials
Important links to related Spikes and Implementation proposals
...
- CPS-1104 Agree LCM Event schemas
- CPS-1119: Define the Initial Data Sync State on each cmhandle registration request
- CPS-1034 Publish LCM Events on Cmhandle State Change(NcmpEventsCmHandleStateHandler)
- Workshop: CM-Handle States & Locking
- CPS-909 Separate NCMP endpoint for cm-handle properties and cm-handle state
- CPS-1014 Yang module update with DataStoreSyncState
- CPS-875 Cm Handle State: Java Enum State Machine
- CPS-877: Exclude any CM-Handles from queries/operations that are not in state 'READY'
- CPS-875 CM Handle State: Watchdog-process that syncs 'ADVISED' CM Handles
- CPS-872 CM Handle State: define and agree new dmi-registry yang model supporting States
- CPS-799 Spike: Define states and state handling for CM handle