Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Related Jira(s)

CPS-1415 - Getting issue details... STATUS


Issues and Decisions

#IssueNotes Decision
1how fast should CPS (and DB) be able to process max heart beat failuresis 60K really realistic if ENM goes down we should get a notification for each node do we ?!

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

#InterfaceRequirementAdditional Information
1CPS-NCMP-I-01The 'trustlevel' can be queried (is visible) on the methos as currently the 'cm handle state'
2CPS-NCMP-I-01Once a CM Handle is registered (TBD which state exactly?) the trust -level for that CM Handle should be  reported to be 'COMPLETE'
3CPS-NCMP-I-01Once DMI (plugin) is detected to be down the trust-level for all affected CM Handles should be reported to be 'NONE'It might not need to be persisted....
4CPS-NCMP-I-01
REST or ASYNC TBD		DMI plugin can report the current trustlevel of a single (or collection?) of cm handle (id)sie. the DMI can tell NCMP the trustlevel is 'NONE' when a  node heartbeat failure is detected and 'COMPLETE' once it is restored
5
Notification on trustlevel changes ?!

Error Handling

#Error ScenarioExpected behavior
1NCMP restartOptions:
  1. Trustlevels should as they were before the restart? (might depend on how much time has elapsed)
  2. (preferred) Trustlevels should be 'NONE' and need to be restored using an audit-request (not in scope)
2

Characteristics

#ParameterExpectationNotes
1dmi-down detection speed60 seconds (TBD)

2maximum number of cm-handles down report by DMI in one request and/or per minute30,000 / minute This looks like an 'ENM down' not sure if that should be handled this way
3processing of all trustlevel time for DMI-Down and/or peak load by DMI 



Out-of-Scope

  1. This epic will only introduce trustlevels NONE and COMPLETE. PARTIAL and POOR may be added later as below.
  2. Re-registration ie. resolve trutslevel degradation is not in scope of this epic


High Level Interactions

InterfaceNameTriggerDescriptionTypeEndpoint or TopicSchema
1HealthCheck30 second interval (configurable)NCMP is to perform a health check against each of the DMI PluginsRESThttp://'$1'/manage/health/readiness
2CMHandle trust level changeA CMHandle managed by DMI Plugin's trust level has changed

data contains {trustLevel: ENUM} 

event id is cmhandle id

KafkaTBD

<cloudEvents-header>

  id : <cmhandleId>

  type : org.onap.cm.events.trustlevel-notification


  data : {

                                trustlevel : "COMPLETE"

  }

3TrustLevel RequestClient RequestTrustLevel is to be returned based on the values in above MapsRESTTBD

Managing TrustLevels

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
  3. IF a DMI Plugin comes back up, Trust level is set back to COMPLETE.

CMHandles HB

  1. It is the responsibility of the DMI Plugins to update NCMP about the HBs of CMHandles
  2. Through interface 4, DMI Plugins will provide a kafka event on the changing of trustworthiness state of a CMHandle.
    1. NCMP receives this event and updates the Untrustworthy CMHandles Set 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 to be discussed, Will the request provide a DMI or a list of CMHandles?
  2. Interface 3
  3. NCMP will first check DMI Trust Map for the CMHandle
    1. If that DMI which is managing the CMHandle is marked as untrustworthy then we return NONE without checking the Untrustworthy CMHandles Map
    2. If that DMI is trustworthy, we check the individual CMHandles Map, if the CMHandle is in the Map then return NONE.
  4. Logically IF (DMITrustMap.getDMIPlugin.getTrustLevel ==  NONE) Return NONE
    1. ELSE (IF UntrustworthyCMHandlesMap.getDMIPlugin.contains(CMHandle) RETURN NONE
    2. ELSE return COMPLETE



  • No labels