CPS-877: Exclude any CM-Handles from queries/operations that are not in state 'READY'

References:

CPS-877: CM Handle State: Exclude any CM-Handles from queries/operations that are not in state 'READY'Closed

Overview

This user story is related to  CPS-875 CM Handle State: Watchdog-process that syncs 'ADVISED' CM Handles.

Recap of watchdog process:

  1. Wake up on a specified schedule

  2. Identify node with state ‘ADVISED’

  3. Lock database, update timestamp, unlock the database

  4. Model sync

  5. 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

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
CPS-E-05 list all methods and check/decide in this study (List of API's given below)

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?



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