Table of Contents |
---|
Overview
Jira | ||||||
---|---|---|---|---|---|---|
|
- Each Cm-Handle state change triggers a LCM event notification sent to the By each LCM state change the related notification is sent to user to notify about the state change.
- When an event a Cm-Handle is registered it will initially be set in an 'ADVISED' state.
- 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 and the data sync-state will be 'NONE_REQUESTED'.
- If the user wants to set data-sync-enabled to true, it has to 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 ADVISED an 'UNSYNCHRONIZED' data sync-state will be picked up by a watchdogthe 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 If there's handles to be deleted during Update than update, then their states will be set to DELETING before the deletion happens after to DELETED
- If Watchdog start to working with a Handle than it changes its state to READY or LOCKED whether DataSync succeeded
- 'DELETING'. Once deletion is complete, the state is set to 'DELETED'.
Diagram of the possible transactions between CM-Handle states
Excerpt Include | ||||
---|---|---|---|---|
|
...
Notification handling in code
Embed draw.io Diagramgliffy | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The Event structure of the notification
Event schema
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
{ "$schema": "https://json-schema.org/draft/2019-09/schema", "$id": "urn:cps:org.onap.ncmp.cmhandle.lcm-event:v1", "$ref": "#/definitions/LcmEvent", "definitions": { "Values": { "description": "Values that represents the state of a cmHandle", "type": "object", "properties": { "dataSyncEnabled":{ "description": "Whether data sync enabled", "type": "boolean" }, "cmHandleState": { "description": "State of cmHandle", "type": "string", "enum": ["ADVISED", "READY", "LOCKED", "DELETING", "DELETED"] }, "cmHandleProperties": { "description": "cmHandle properties", "type": "object", "default": null, "existingJavaType": "java.util.List<java.util.Map<String,String>>", "additionalProperties": false } }, "additionalProperties": false }, "Event": { "description": "The Payload of an event", "type": "object", "properties": { "cmHandleId": { "description": "cmHandle id", "type": "string" }, "oldValues": { "$ref": "#/definitions/Values" }, "newValues": { "$ref": "#/definitions/Values" } }, "required": [ "cmHandleId" ], "additionalProperties": false }, "LcmEvent": { "description": "The payload for LCM event", "type": "object", "javaType" : "org.onap.ncmp.cmhandle.event.lcm.LcmEvent", "properties": { "eventId": { "description": "The unique id identifying the event", "type": "string" }, "eventCorrelationId": { "description": "The id identifying the event", "type": "string" }, "eventTime": { "description": "The timestamp when original event occurred", "type": "string" }, "eventSource": { "description": "The source of the event", "type": "string" }, "eventType": { "description": "The type of the event", "type": "string" }, "eventSchema": { "description": "The schema that this event adheres to", "type": "string" }, "eventSchemaVersion": { "description": "The version of the schema that this event adheres to", "type": "string" }, "event": { "$ref": "#/definitions/Event" } }, "required": [ "eventId", "eventCorrelationId", "eventTime", "eventSource", "eventType", "eventSchema", "eventSchemaVersion", "event" ], "additionalProperties": false } } } |
...
Gliffy Diagram | ||||||||
---|---|---|---|---|---|---|---|---|
|
State changes after cm Handle update received
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
State changes
...
during module-sync watchdog execution
Gliffy Diagram | |||||
---|---|---|---|---|---|
|
...
|
State changes during data-sync watchdog execution
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
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
...