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 R1vFW, 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
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" (NEW, 8/25/17) 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:
NEW, 8/25/17
- 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
Data Flow Diagram, v1 - Flow 7b
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.
TODO: update these samples to be consistent with sample policy and, if possible, to reflect data received from the VES collector in the ONAP lab.
Sample 1 - Sample data for vFW and vDNS use cases; ves5.3-measurement-vf5vdns.txt
ves5.3-measurement-vf5vdns.txt
expand source?
1 |
|
Sample 2 - Sample data for general VES 5.3 use cases; VES-5.3-measurement-mockup.txt
VES-5.3-measurement-mockup.txt
expand source?
1 |
|
MR Interface - Sink (aka Control Loop Event Message)
Data Flow Diagram, v1 - Flow 8a
The output TCA alert format is constructed as shown in Table 1. (NEW, 8/25/17) The description field below is copied from the Control Loop Event Message section here.
Table 1: Format of the Output Alert from the cdap-tca-hi-lo Microservice
JSON Field | JSON sub-field | Populate Using | Description |
|---|---|---|---|
JSON Field | JSON sub-field | Populate Using | Description |
| { | |||
| closedLoopControlName | closedLoopControlName included in the DCAE configuration Policy | The unique ID for the Control Loop. It is created by the CLAMP platform during Control Loop design. The DCAE Micro service that publishes this event structure MUST include this ID. | |
| version | version included in the DCAE configuration Policy | The version of the Control Loop event message. Should be '1.0.2'. | |
| requestID | Generate a UUID for this output message | For the control loop, when an instance of the Control Loop occurs, this unique ID must be created. The same ID must be forwarded for both the ONSET and the ABATED control loop messages. | |
| closedLoopAlarmStart | commonEventHeader.startEpochMicrosec from the received VES measurementsForVfScaling message | When the alarm was first detected. | |
| closedLoopEventClient | Concatenate name of this DCAE instance and name for this TCA instance, separated by "." | For monitoring/logging/auditing purposes, if there is an instance ID of the DCAE micro service this field should be populated with it. | |
| target_type | "VNF" | The type of the target: VM or VNF. Future PNF(?). | |
| target | "generic-vnf.vnf-id" or "vserver.vserver-name" | This is the name of the field within the A&AI sub-tag that indicates the actual entity Node details. There should be a matching node field within the A&AI subtag holding this value. | |
| AAI | { | Contains the A&AI Node-Attribute list. | |
generic-vnf.vnf-id | commonEventHeader.reportingEntityName from the received VES measurementsForVfScaling message (value for the data element used in A&AI) | ||
| } | |||
| from | "DCAE" | The ONAP platform component publishing this message. If DCAE, then it should be 'DCAE'. | |
| policyScope | policyScope included in the DCAE configuration Policy | The version of the Policy driving the DCAE Micro service. Should be a part of the configuration policy setup by CLAMP and passed by DCAE controller. | |
| policyName | policyName included in the DCAE configuration Policy | The version of the Policy driving the DCAE Micro service. Should be a part of the configuration policy setup by CLAMP and passed by DCAE controller. | |
| policyVersion | policyVersion included in the DCAE configuration Policy | The version of the Policy driving the DCAE Micro service. Should be a part of the configuration policy setup by CLAMP and passed by DCAE controller. | |
| closedLoopEventStatus | "ONSET" |
TODO, 8/25/17 - review the ABATED proposal for ONAP R1 and determine whether we need to add closedLoopAlarmEnd, assume yes.
TODO, 8/25/17 - review, with Ron S, the notion of separate closedLoopControlNames for high and low thresholds as shown in our sample policy; is this actually how a control loop would be configured? Our expectation is that for the vCPE use case the closedLoopControlName will be the same since the ABATED event would need to be correlated to the ONSET event for that same CL.
TODO, 8/25/17 - what does Policy do if it receives an ABATED w/o a corresponding ONSET? Does Policy (or APPC) keep such state?
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"
Sample 3 - Sample Control Loop Event Message for vFW demo, "controlLoopSchemaType": "VNF"
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"
Sample 4 - Sample Control Loop Event Message for vDNS/vLB demo, "controlLoopSchemaType": "VM"
In both cases, the value of the fields, generic-vnf.vnf-id and vserver.vserver-name, is constructed from the incoming VES measurementsForVfScaling message received from the upstream collector in the field: commonEventHeader.reportingEntityName.
Policy Interface
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.
Table 2: Configurable Properties Exposed through the Policy Interface
JSON Field | JSON sub-field | Description | Notes |
|---|---|---|---|
JSON Field | JSON sub-field | Description | Notes |
| { | |||
| domain | the domain datatype of the VES message | Must be measurementsForVfScaling | |
| metricsPerEventName | [ { | an array that describes parameters associating a closed loop flow to the policy governing this TCA instance | |
| eventName | a unique identifier that represents an event name that this TCA instance will act on | From VES 5.3 spec: "It should be understood that events are well structured packages of information, identified by an eventName, which are asynchronously communicated to subscribers who are interested in the eventName. Events can convey measurements, faults, syslogs, threshold crossing alerts and others types of information. Events are simply a way of communicating well-structured packages of information to one or more instances of an Event Listener service." | |
| controlLoopSchemaType | this is a field which will be used to derive the schema of the Control Loop Event Message | Valid values for the Amsterdam release: VM | VNF | |
| policyScope | the scope of this policy message | ||
| policyName | a name identifying this policy message | ||
| policyVersion | a version identifying this policy message | ||
| thresholds | an array of one or more thresholds that are managed as part of a given closed loop | ||
| closedLoopControlName | the name that specifies which control loop this TCA instance is a part of | ||
| version | the version of the control loop | ||
| fieldPath | a value used to derive the metric within VES message that this TCA will apply to | expected to be part of a measurementsForVfScaling domain event message | |
| thresholdValue | the value of the metric which will trigger this threshold | must be numeric | |
| direction | |||
| severity | an identifier specifying the precendence of this threshold evalution; thresholds will be evaluated from highest severity (CRITICAL) to lowest (NORMAL); a given VES message will only trigger one threshold | expected values: CRITICAL | MAJOR | MINOR | WARNING| NORMAL | |
| closedLoopEventStatus | an identifier used to describe whether this threshold should be associated with a control loop ONSET action or whether it would describe a condition that indicates such a condition has ended (i.e. the condition has ABATED). Note that ABATED alerts will be correlated to ONSET events based on the following key fields (9/11/17, TODO: add key fields here) | expected values: ONSET | ABATED |
As compared to the ONAP R0 release where the configuration policy was flattened into a series of key-value pairs, in the ONAP R1 release, such config info will be passed from the controller to the CDAP app as a complex json object. A design goal for creating the schema for this policy model was to insure that the model was extensible so that a single instance of TCA could handle one or more use cases without alteration to the schema. That said, for the Amsterdam/ONAP R1 release, we are expecting to have a single instance of TCA deployed via CLAMP for each use case. Samples 5 through 7 illustrate a sample config policy that is expected with each use case while Sample 8 shows how a single instance could receive the policy config for all use cases.
Sample 5 - Sample Policy, as Complex Json, Illustrating the vFW use case
Sample 6 - Sample Policy, as Complex Json, Illustrating the vDN/vLB use case
Sample 7 - Sample Policy, as Complex Json, Illustrating the vCPE use case
Sample 8 - Sample Policy, Illustrating How the Policy Model is Extensible to More than One Use Case
SME(s):
Business Sponsor(s):
provide contact information for the sponsor of this microservice. This should be the individual or organizations that are providing funding and/or are otherwise responsible for the lifecycle of the application code.
Contact | Role | Notes |
|---|---|---|
Contact | Role | Notes |
| ONAP TSC | Technical Steering Committee | This microservice was specifically developed for ONAP R0 and later enhanced for ONAP R1. Functionally, it has similarities to the cdap-mtca microservice used in 1707/1710 attECOMP however the code bases are different. |
Known Service Use Case(s):
provide a short description of any known service use cases to include the VFs involved, the end services impacted, etc.