...
- dmi plugin identifies that the device is no longer contactable.
- dmi plugin identifies that an underlying device manager managing the device (node) is out of sync with the device itself.
Requirements
Functional
# | Interface | Requirement | Additional Information | Sign-off |
---|---|---|---|---|
1 | CPS-NCMP-E-05 | The 'trustlevel' is visible on all REST methods that currently include the 'cm handle state' | existing endpoints |
|
2 | CPS-NCMP-E-05 | CM Handles can be queried (filter condition) on 'trustlevel' | using a new 'trustLevel' condition (cannot use cpsPath condition) |
|
3 | CPS-NCMP-I-01 | During registration, DMI plugin can report initial trustlevel. If the state is not 'complete', it should be considered as 'Trustlevel change' (See req 5) | Initial trust level will be backward compatible if not set, we assume trustlevel is 'complete' For a new cm-handle where the trustlevel is 'complete' this is NOT considered a chance and no notifications should be sent |
|
4 | CPS-NCMP-E-05 | Once DMI (plugin) is detected to be down the trust-level for all affected CM Handles should be set to be 'NONE'. This wil also lead to many notifcations as per req. #5 | this might lead to a high level (20K) of notifications (need to discuss capabilities) |
|
5 | CPS-NCMP-E-05.e | NCMP notification shall be sent when the trustlevel changes | Notification be sent externally based on Kafka many small or bulk: Agreed Many notifications, one for each cm-handle |
|
6 | CPS-NCMP-I-01.e | It shall be possible to report any trustlevel of one CM Handle DMI plugin can report the current trustLevel of a single cm handle id | i.e. the DMI can tell NCMP the trustLevel is 'NONE' when a node heartbeat failure is detected and 'COMPLETE' once it is restored. Again this should lead to notifications on the external interface as per req #5 |
|
...
# | Error Scenario | Expected behavior | Sign-off |
---|---|---|---|
1 | NCMP restart (all instances) | To be discussed, not sure if it can/should be handled TrustLevels should be 'NONE' and need to be restored using an audit-request (not in scope) | If we restart, it should go into COMPLETE STATE. No way of getting out of NONE State Audit was agreed to be handled in a separate epic - Prioritise audit epic
Team Notes: 12/10/2023 **If all instances of NCMP restarts [fresh start], there would be nothing in the cache |
Characteristics
# | Parameter | Expectation | Notes | Sign-off |
---|---|---|---|---|
1 | dmi-down detection speed | 60 seconds | It's a configurable value. Agreed - Should be in parallel with device heartbeat. |
|
2 | device heartbeat frequency (message emitted by DMI plugin for each device) | 60 seconds | Can be removed - out of scope for this epic | |
3 | maximum supported devices (by NCMP) | 60,0000 | Given #2 and #3 this means NCMP needs to process 60,000 message / minute! - Can be removed, separate epic - out of scope for this epic | |
4 | maximum number of cm-handles down report by DMI in one request and/or per minute | 30,000 / minute | a peak can be processed within 60 seconds |
|
5 | processing of all trustLevel time for DMI-Down and/or peak load by DMI | 1 second | Agreed to go with 30,000 / minute as no 4 |
|
6 | If we incorporate into searches endpoints the speed should not be impacted | 30 seconds | Speed shouldn't be affected - Agreed - It's across 60,0000 cmHandle Open for improvement in respect to performance |
|
...
draw.io Diagram | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Interface | Name | Trigger | Description | Type | Endpoint or Topic | Schema |
---|---|---|---|---|---|---|
1 | HealthCheck | 30 second interval (configurable) | NCMP is to perform a health check against each of the DMI Plugins | REST | http://<dmiPluginServiceName>/manage/health This endpoint will be the standard heath check endpoint provided by spring boot actuator. We don't store it anywhere. We just document it for now. | |
2 | CMHandle trust level change | A CMHandle managed by DMI Plugin's trust level has changed | data contains {trustLevel: ENUM} event id is cmhandle id in kafka header | Kafka | kafka topic: dmi-device-heartbeat | <cloudEvents-header> id : <cmhandleId> type : org.onap.cm.events.trustlevel-notification data : { |
3 | CMHandle Query API with trustLevel Query Condition | Client Request | CmHandle is to be returned based on the values in above CMHandle Trust Map | REST |
| { |
4 | Notification on Trust Level Change | NCMP | NCMP sends notification upon trust level changes | Kafka | kafka-topic: cm-events | <cloudEvents-headers> "data": { |
Managing TrustLevel
DMI Plugins
...
- It is the responsibility of the DMI Plugins to update NCMP about the heartbeat of CMHandle.
- Through interface 2, DMI Plugins will provide a Kafka event on the changing of trustworthiness state of a CMHandle.
- NCMP receives this event and updates the CM Handle Trust Map accordingly
- Needs to be able to handle a throughput of 60,000 State changes per minute for 2 instances
...
Query CM Handle with Trust Level
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- Interface 3
- NCMP will first check trust level query parameters to determine which trust level (NONE, COMPLETE) is being searched.
- if Then, the target trust level is NONE
- The cm handles stored in CM Handle Trust Map having NONE will be returned.
must be selected. - If the target trust level is COMPLETEThe cm handles stored in CM Handle Trust Map having COMPLETE 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.
- if Then, the target trust level is NONE
Notifications on Trust Level Changes
...
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
Element | Name | Parent | Type | Mandatory | Description | Format | (example) Value | |
---|---|---|---|---|---|---|---|---|
1 | Header | id | String | Yes | random id for cloud event header. UUID is suggested | |||
2 | source | String | Yes | source of information | ncmp.<cmhandle-id> | ncmp.12ac34e43556e | ||
3 | specversion | String | Yes | cloud event version spec | fixed value | 1.0 | ||
4 | type | String | Yes | type of event | fixed value | trustLevelChangeEvent | ||
5 | dataschema | String | Yes | data schema | fixed value | org.onap.cps.ncmp.events.cmhandle.TrustLevelChangeEvent:1.0.0 | ||
6 | correlationid | String | Yes | The cmHandle which is been notified. The value will be similar as we have in the source field. | <cmhandle-id> | |||
7 | Payload | data | Object | Yes | The actual data payload. Details will be provided below. | 3GPP TS 28.532 standard | ||
8 | attributeName | data | String | Yes | The attribute which has changed. | <name> | trustLevel | |
9 | oldAttributeValue | data | String | No | The old value of the attribute which has changed. | COMPLETE | ||
10 | newAttributeValue | data | String | No | The new value of the attribute which has changed. | NONE |