References:
CPS-877 - Getting issue details... STATUS
Overview
This user story is related to CPS-875 CM Handle State: Watchdog-process that syncs 'ADVISED' CM Handles.
Recap of watchdog process:
- Wake up on a specified schedule
- Identify node with state ‘ADVISED’
- Lock database, update timestamp, unlock the database
- Model sync
- Update state of the node to ‘READY’
As part of this story, only CM-Handles with a state of ready should be returned as part of queries or operations in regard to CM-Handles.
Issues and decisions
| # | Questions/Open Issues | Notes | Decision/Answer |
|---|---|---|---|
| 1 | Should state details be part of Response - get CM Handles Request | Don't think so. Check with Stakeholder | Do not return state details as part of this change, may be added later as needed. |
| 2 | Should filter be applied to the API which queries cm handles based on public properties | Check with Stakeholder | Should still return all cm-handles regardless of state. |
| 3 | Are all data API's which interact with CM-Handles affected by this - such as GET/POST/PATCH/DELETE operations | CPS-NCMP ↔ DMI-Plugin Interface Details Jakarta-R10 Also consider CPS-NCMP-I-01 | |
| 4 | What is the default value of a state if it is not specified when registering a cm-handle. | Consider anything as NOT equals to 'READY' as NOT ready | 'ADVISED' |
| 5 | Should the user be told if the cm-handle isn't 'READY'? | Should any excluded cm-handles as part of a query/operation be explicitly stated to the user? If yes, should any query which can potentially return multiple cm-handles also state if CM-Handles haven't been returned due to not being in a 'READY' state? | Yes, return error message citing state mismatch, on passthrough. |
| 6 | Should Passthrough READ be able to retrieve locked Cm Handle details. | No, for now LOCKED states are treated the same as ADVISED states |
List of API's and possible impact.
| # | HTTP Method | Endpoint | Possible Impact | Included in this change? |
|---|---|---|---|---|
| 1 | GET | /v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-operational | The given Cm-Handle's resource data cannot be obtained through passthrough operational if state is not 'READY'. | Yes |
| 2 | GET | /v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-running | The given Cm-Handle's resource data cannot be obtained through passthrough running if state is not 'READY'. | Yes |
| 3 | PUT | /v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-running | The given CM-Handles resource data cannot be updated if the state is not READY. | Yes |
| 4 | POST | /v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-running | The given CM-Handles resource data cannot be created if the state is not 'READY'. | Yes |
| 5 | DELETE | /v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-running | The given CM-Handles resource data cannot be deleted if the state is not 'READY' | Yes |
| 6 | PATCH | /v1/ch/{cm-handle}/data/ds/ncmp-datastore:passthrough-running | The given CM-Handles resource data cannot be partially updated if the state is not 'READY'. | Yes |
| 7 | POST | /v1/ch/searches | CM-Handles not in the 'READY' will not be returned for the given such module names | No |
| 8 | GET | /v1/ch/{cm-handle} | CM-Handle details won't be given for the following CM-Handle if it is not in a 'READY' state. | No |
| 9 | POST | v1/data/ch/searches | CM-Handles won't be returned based on the properties provided if they are not in a 'READY' state. | No |
| 10 | POST | /ncmpInventory/v1/ch | No |