/
CPS-1119: Define the Initial Data Sync State on each cmhandle registration request

CPS-1119: Define the Initial Data Sync State on each cmhandle registration request

Jun 30, 2022

References:

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Overview

This user story relates to CPS-1119 Define the Initial Data Sync State on each cmhandle registration request

Current Process:

  1. Cm Handle Is Registered in Advised State

  2. Watchdog Process Wakes Up, set state to READY

  3. The dataSyncState is set to UNSYCHRONIZED as part of the following user commit (https://gerrit.onap.org/r/c/cps/+/129720)

New Process:

  1. Cm Handle Is Registered in Advised State,

  2. Set and persist dataSyncEnabled flag

  3. Watchdog Process Wakes Up, set state to READY

  4. Based on the dataSyncEnabled flag, the default state is set to UNSYCHRONIZED or NONE_REQUESTED

  5. The data sync watchdog should pick up any cm handles found in the UNSYCHRONIZED state.

Issues/Decisions

Questions/Open Issues

Notes

Decision/Answer

Questions/Open Issues

Notes

Decision/Answer

1

How is dataSyncEnabled set?

Presumably during the registration process (ie part of POST body), options 

  1. an 'additionalProperty' (now call DMI properties)

  2. a public properties (mean it will be seen and can be queried)

  3. separate new (optional) json property for each cm-handle



2

What is the default state (if nor provide assuming new parameter is optional)

Presumably UNSYNCHRONIZED if data sync enabled flag is true, and NONE_REQUESTED if data sync enabled flag is false.



3

Does update functionality as part of cm handle registration have any effect on the data sync state and in turn the dataSyncEnabled flag?

Consider

  1. Changing from Disabled to Enabled (easy?)

  2. Changing from Enabled to Disabled (clean-up data?)