Related Jira(s)

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

...

Capabilities

1. re-registration, once a day, same requirement as first time registration
2. single node heart beat failures 30,000 / minutes per instances

Scope

1. Currently only supporting NONE and COMPLETE. PARTIAL and POOR may be added later as below.

Changes to DMI Registry Model

We will not be making changes to the DMI Registry Model, Public Properties of the CMHandle will be used where needed.

Triggers of CMHandle trust level change

Image Removed

DMI Availability

Ping every 30 seconds configurable or (every communication with DMI OOS)

Health check endpoint already exists 

http://'$1'/manage/health/readiness

Hazelcast Map

When DMI comes back up, DMI does audit and provides list of Trustworthy CM Handles

Audit triggered by NCMP with list of CMHandles IDs and for DMI to reregister HTTP

Deltas: DMI handling, properties; Delete all under a DMI? Performance?

...

Device Heart Beat

Assumed functionality is that this will be defined by the DMI Plugin as NCMP does not communicate with device directly

Interface in NCMP for DMI Plugin to be able to tell when device HB has been lost?

10 minute limit should be configurable with 10 as default.

Probably event based

...

DMI-I-01

/health

/v1/ch/trustlevel

{

"Trust":

}

Reregistration

This process occurs when the DMI Plugin Availability is down and then comes back up.
NCMP makes a synchronous call to the DMI Plugin (New Audit Endpoint) to trigger a reregistration
DMI Plugin then reregisters its CMHandles with NCMP (new reregistaration Endpoint?)
NCMP then compares the CMHandles which are being reregistered with the CMHandles which already exist.
CMHandles which are in NCMP but not in DMI reregistration request are kept as trust level none
What happens if there is conflict between the old and new properties of a CMHandle, just take the new properties?
New CMHandles could be registered

Hazelcast for Trust Level

Map Trust level for DMI Plugins
Key: Dmi Name, Values: health check url, trust level

Set Trust level for untrustworthy CMHandles
Key: CmHandleId

...

Error Handling

Characteristics

Out-of-Scope

1. This epic will only introduce 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 epic

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 Map
2. IF a DMI Plugin goes down, that DMI Plugin's health status is updated to NONE in the Trust Level DMI Map
   1. The CM handles corresponding to DMI should be set to NONE.
3. IF a DMI Plugin comes back up, 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 heartbeat of CMHandle.
2. Through interface 2, DMI Plugins will provide a Kafka event on the changing of trustworthiness state of a CMHandle.
   1. NCMP receives this event and updates the CM 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.
   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 (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