| 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 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 watchdogIf there's handles to be deleted than their states will set to DELETING before the deletion happensthe 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'. 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
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
}
}
}
|
...
Typical use cases which leads to state changes and trigger notification events
State changes after new cm Handle is registered
| 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