| 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 cm handle 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 state and ' 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 a module-sync watchdogand the data sync-state will be 'NONE_REQUESTED'.
- If the user wants to have 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 a 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 there's the handles are to be deleted during Update update, then their states will be set to 'DELETING before the deletion happens, then after it to DELETED
- If a data-sync watchdog starts to work with a cm Handle then it changes its state to READY or LOCKED whether data-sync succeeded
- '. 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
}
}
}
|
...
| 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