Related Jira(s)

Assumptions

...

Partial Demo

This demo includes the functional requirements Req. 2 and Req. 6 fully and Req. 4 is partially included.

13 Oct 2023 CPS User Story Demos

Assumptions

Issues and Decisions

Description

1. Define scenarios which cause a CM Handle to go stale.
2. Implement changes to support tracking of CM Handle Freshness/Staleness.

What might trigger a cmHandle to go to STALE?

1. dmi plugin identifies that the device is no longer contactable.
2. dmi plugin identifies that an underlying device manager managing the device (node) is out of sync with the device itself. 

Requirements

Functional

Error Handling

Characteristics

Out-of-Scope

1. This epic will only introduce trustLevels trustLevel NONE and COMPLETE. PARTIAL and POOR may be added later as below.
2. Re-registration i.e. resolving trutsLevel degradation is not in scope of this epicNCMP will not send notification on trustLevel changes for external consumers

High Level Interactions

...

Managing TrustLevel

DMI Plugins

1. NCMP is checking every DMI Plugin for health at interface 1 every 30 seconds using the Trust Level DMI Trust Map
2. IF a DMI Plugin goes down, that DMI Plugin's trust level health status is updated to NONE in the Trust Level DMI Trust MapMap
   1. The CM handles corresponding to DMI should be set to NONE.
3. IF a DMI Plugin comes back up, Trust level Heath status is set back to COMPLETE for that DMI plugin only.
   
   More details of health check URL can be accessed via:
   CPS-1857 Document watchdog job impl. with health check URL

...

CMHandle Heartbeat

1. It is the responsibility of the DMI Plugins to update NCMP about the HBs heartbeat of CMHandlesCMHandle.
2. Through interface 2, DMI Plugins will provide a kafka Kafka event on the changing of trustworthiness state of a CMHandle.
   1. NCMP receives this event and updates the Untrustworthy CMHandles Set accordinglyCM Handle Trust Map accordingly
3. Needs to be able to handle a throughput of 60,000 State changes per minute for 2 instances

...

Query CM Handle with Trust Level

1. Body of request will be in the format as below:

   Code Block
   language text title Search Trust Level Request Body
   { "cmHandleQueryParameters": [ { "conditionName": "cmHandleWithTrustLevel", "conditionParameters": [ {"trustLevel": "COMPLETE"} ] } ] }

   
   

   There are two end points will be subject to query:
   http://<host>:<port>/ncmp/v1/ch/id-searches
   http://<host>:<port>/v1/ch/searches 
   
   
2. Interface 3
3. NCMP will first check trust level query parameters to determine which trust level (NONE, COMPLETE) is being searched.if .
   1. Then, the trust level for both DMI and CM Handle should be compared, and minimum of two (effective trust level)
      must be selected.
   2. If the target trust level is NONE
      1. The cm handles stored in untrustworthyCmHandleSet will be returned.
      if the target trust level is COMPLETE
   3. If that DMI which is managing the CMHandle is marked as untrustworthy then we return NONE
   If that DMI is trustworthy, the cm handles for that DMI will be returned.(comes from the request) is equal to effective trust level (obtained in step a.),
   then cm handle should be included in the response.

Notifications on Trust Level Changes

NCMP will send timely notifications in case of any alterations in a device's trust level via Kafka interface.

Proposal for Notification's Schema

kafka-key : cmHandleId ( *Note : when publishing the notification , use the cmHandleId as the key of the message. This will enable clients to read the most updated message/state when the compaction is triggered)

Cloud event Definition