Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Related Jira(s):

Jira
serverONAP Jira
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyCPS-1415


Description

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

...

  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. 

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

DMI Availability

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

...

DMI AvailabilityTrust Level
AvailableFULL
UnavailableNONE

Device Heart Beat

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

...

10 minute limit should be configurable with 10 as default.

Probably event based

Elapsed time since last DMI Plugin lost Device HBTrust Level
Less than 10 minutesCOMPLETE
Over 10 minutesNONE

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

...

When checking the trust level for a CMHandle first check the trust level of that CMHandle's DMI Plugin
If None return None
If Complete Full check trust level for the CMHandle and return that

Last Data Update

OUT OF SCOPE

Trust Level defined by Client's use of NCMP endpoints to change data related to a CMHandle (passthrough only).

...

Open Question: External Notifications NCMP is subscribed to should effect this?

IssueDescriptionAnswer
CM Handle sync

Assumption is that at CMHandle registration the CMHandle is originally persisted as NONE trustLevel

As CMHandle moves to READY, NONE moves to COMPLETE, Else stays as NONE

The DataSync does not effect this as is related to cache.


What Data?

What about changes to the CMHandle Properties etc?


Last Data UpdateExternal Notifications NCMP is subscribed to should effect this?

Schema Model Mismatch

OUT OF SCOPE

Occurs when data change has been called for a CMHandle and the data change does not fit the defined schema for that CMHandle Anchor (passthrough only).

If this error occurs Trust Level is set to NONE. 

Open Questions

IssueDescriptionAnswer
Storing Trust Level

Do we have to store the trust level or can it be calculated when asked?

Storing in a Hazelcast Map
InterfaceWhat is the interface for getting the trust level going to beNew endpoint