Overview
- By each LCM state change the related notification is sent to user to notify about the state change
- When an event is registered it will be in ADVISED state
- Only the handles with ADVISED state will be picked up by a watchdog
Diagram of the possible transactions between CM-Handle states
| Excerpt Include | ||||
|---|---|---|---|---|
|
Notification details
Notification handling in code
| Embed draw.io Diagram | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
The Event structure of the notification
| Excerpt Include | ||||
|---|---|---|---|---|
|
Typical use cases which leads to state changes and trigger notification events
State changes after Handle is registered
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
State changes happens after Handle is updated
State changes happens during watchdog execution
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
Materials
Important links to related Spikes and Implementation proposals
(From latest to older ones)
- 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