Related Jira(s)

CPS-1415 - Getting issue details... STATUS

CPS-1638 - Getting issue details... STATUS

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 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 DMI Trust Map
2. IF a DMI Plugin goes down, that DMI Plugin's trust level is updated to NONE in the DMI Trust Map
   1. The CM handles corresponding to DMI should be set to NONE.
3. IF a DMI Plugin comes back up, Trust level 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

Reading Trust Level

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

   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. if the target trust level is NONE
      1. The cm handles stored in CM Handle Trust Map having NONE will be returned.
   2. if the target trust level is COMPLETE
      1. The cm handles stored in CM Handle Trust Map having COMPLETE will be returned.

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

12/10/2023 - awaiting for approval

(Reference CPS-1104 Agree LCM Event schemas) 

kafka-key : cmHandleId/deviceId

id : "random UUID"
source : "NCMP"
specversion	: "1.0"
type : "deviceTrustLevelNotification"
dataschema : "org.onap.cps.ncmp.events.trustlevel.DeviceTrustLevelNotification:1.0.0"
correlationid : "deviceId+trustLevel"
"data": {
	"deviceId": "CmHandle1",  // or we can call it cmHandleId as well [mandatory]
	"oldValues": {  // optional
			"trustLevel" : "NONE"
				},
	"newValues" : { // optional
			"trustLevel" : "COMPLETE"
		}
}