...
- Cm Handle Is Registered in Advised State
- Watchdog Process Wakes Up, set state to READY
- The data sync state dataSyncState is set to UNSYCHRONIZED as part of the following user commit (https://gerrit.onap.org/r/c/cps/+/129720)
...
- Cm Handle Is Registered in Advised State,
- Set and persist dataSyncEnabled flag
- Watchdog Process Wakes Up, set state to READY
- Based on the data sync enabled dataSyncEnabled flag, the default state is set to UNSYCHRONIZED or NONE_REQUESTED
- The data sync watchdog should pick up any cm handles found in the UNSYCHRONIZED state.
Issues/Decisions
| # | Questions/Open Issues | Notes | Decision/Answer |
|---|
| 1 | How is |
data sync enabled 4 | | dataSyncEnabled set? | Presumably during the registration process (ie part of POST body), optionsÂ
- an 'additionalProperty' (now call DMI properties)
- a public properties (mean it will be seen and can be queried)
- 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 |
Is Data Sync State part of the registration request POST api Body? | | Does update functionality as part of cm handle registration have any effect on the data sync state and in turn the |
dtata sync enabled flag?| dataSyncEnabled flag? | Consider - Changing from Disabled to Enabled (easy?)
- Changing from Enabled to Disabled (clean-up data?)
|
|
