TCA application

cdap-tca-hi-lo: a TCA application enhanced for Amsterdam/ONAP R1

This page is intended to give a broad overview of a microservice which has been onboarded with the DCAE platform and should be considered the "launch page" for others to find out basic information about your microservice.  "Others" will include testers, DCAE/ASDC Service Designers, team members from other subsystems (Policy, CLAMP), etc. 

Name:

cdap-tca-hi-lo

Synopsis/Description:

The cdap-tca-hi-lo app was first delivered as part of ONAP R0.  In that release, it was intended to be an application that established a software architecture for building CDAP applications that demonstrate sufficient unit test coverage and reusable libraries for ingesting DMaaP MR feeds formatted according to the VES standard.  Functionally, it performs a simple comparison of an incoming performance metric(s) against both a high and low threshold.

In the Amsterdam release, this microservice will be enhanced roadmap to meet the release requirements.  The code will be used in the following ONAP use cases:

• Enhance TCA app to support R1 vCPE use case (requires new configuration model)

•  

  • also needs to support the ONAP R1 vFW, vDNS/vLB use cases

  •  

    • unchanged from R0 DCAE analytics perspective; primary difference is the deployment of the TCA app is via CLAMP and the new DCAE controller

Gerrit:

• dcaegen2/analytics/tca.git/summary

Sonar:

• https://sonar.onap.org/overview?id=org.onap.dcaegen2.analytics.tca%3Adcae-analytics

Jira:

• https://jira.onap.org/browse/DCAEGEN2-123?jql=labels%20%3D%20cdap-tca-hi-lo

  DCAEGEN2-123 - TCA needs to have fall-back for obtaining of DMaaP preferences

  DCAEGEN2-116 - Add support for VES/A&AI enrichment within the CDAP TCA app

  DCAEGEN2-107 - Add support for ABATED alerts within the CDAP TCA app

  DCAEGEN2-65 - Analytics app upgrade to support 5.x

• Deferred to Beijing Release:

  DCAEGEN2-119 - Update CDAP/TCA application

Detailed Description:

This CDAP application is driven by the VES collector which outputs to Message Router.  This Message Router topic is the source for the CDAP application which will read each incoming message. If a message meets the Common Event Format (CEF, v28.3) as specified by the VES 5.3 standard (AttServiceSpecification-VesEventListener-v5.3.docx, Rev: 5.3, 6/22/17), it will be parsed and if it contains a message which matches the policy configuration for a given metric (denoted primarily by the "eventName" and the "fieldPath"), the value of the metric will be compared to the "thresholdValue".  If that comparison indicates that a Control Loop Event Message should be generated, the application will output the alarm to the Message Router Sink topic in a format that matches the interface spec defined in the ONAP Control Loop Operational Policy (see section titled "Control Loop Event Messages").

Assumptions:

TCA output will be similar to R0 implementation, where CL event will be triggered each time threshold rules are met.

• Support for ABATEMENT event is not strictly necessary in the vFW or vDNS/vLB use cases as the Policy team has an "ABATEMENT not expected" configuration setting.  In the context of the vCPE use case, the CLEAR event (aka ABATED event) is driven by a measured metric (i.e. packet loss equal to 0) rather than by the lapse of a threshold crossing event over some minimum number of measured intervals.  Thus, this requirement can be accommodated by use of the low threshold with a policy of "direction =  0".  Hence, for this release, the cdap-tca-hi-lo implementation will keep only the minimal state needed to correlate an ABATED event with the corresponding ONSET event.  This correlation will be indicated by the requestID in the Control Loop Event Message.

CDAP Programming Paradigm

The ONAP R0 version of this microservice was built using the flowlet paradigm.  We have also successfully built it as a batch pipeline.  For Amsterdam/ONAP R1, the code has been refactored to allow for delivery as either a flowlet or a batch pipeline.  We expect that for this release the implementation will stay with the flowlet version since other parts of the DCAE platform do not yet support CDAP pipelines.

Public APIs:

MR Interface - Source

The source interface to TCA is Message Router; the input topic is expected to contain CEF messages (v28.3) as defined in the VES specification.  Sample 1 and Sample 2 contain sample data based on the known schema in this spec as of 8/9/17.  This data can be used as a guide for planning and development, but should not be considered authoritative for any of the use cases.

ves5.3-measurement-vf5vdns.txt

VES-5.3-measurement-mockup.txt

MR Interface - Sink (aka Control Loop Event Message)

The output TCA alert format is constructed as shown in Table 1.  The description field below is copied from the Control Loop Event Message section here.

Note 1:  For the case where the VES reporting entity is a VM, the following enrichment fields will be added to the AAI object:

"AAI": {
    "vserver.in-maint": value,
    "vserver.is-closed-loop-disabled": value,
    "vserver.prov-status": value,
    "vserver.resource-version": value
    "vserver.vserver-id": value,
    "vserver.vserver-name": value,
    "vserver.vserver-name2": value
    "vserver.vserver-selflink": value    
}

For the vFW demo, a sample output alert sent to MR is as shown in Sample 3.  Note, this output will correspond to a control loop where the config policy contains:

• "controlLoopSchemaType":  "VNF"

• and the A&AI enrichment query fails or A&AI enrichment is disabled by setting the preference "enableAAIEnrichment" : false

For the vDNS/vLB demo, per UCA-7, in ONAP R0, the output alert sent to MR was modified to be as shown in Sample 4.  This same output format is expected in ONAP R1 and it will be accompanied by a control loop where the config policy contains:

• "controlLoopSchemaType":  "VM"

• and the A&AI enrichment query fails or A&AI enrichment is disabled by setting the preference "enableAAIEnrichment" : false

In both cases, the value of the fields, generic-vnf.vnf-name and vserver.vserver-name, is constructed from the incoming VES measurementsForVfScaling message received from the upstream collector in the field: commonEventHeader.sourceName.

Policy Interface (Control Loop Event structure)

In the Data Flow Diagram, v1 - Flow 3c, the Policy Interface described here is shown in Flow 3c.  This is how the application gets its policy config, whether it comes at deployment and instantiation time via an ASDC blueprint (Flow 2a), or, in later releases, based on being reconfigured by CLAMP via Policy, Flow 3a+3b.

The configurable properties that are exposed on the cdap-tca-hi-lo policy interface are shown in Table 2.