CPS-877: Exclude any CM-Handles from queries/operations that are not in state 'READY'
References:
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 |