ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <>
Subject [jira] [Commented] (AMBARI-8400) Alerts: Template Engine for Dispatching
Date Thu, 20 Nov 2014 21:39:34 GMT


Hadoop QA commented on AMBARI-8400:

{color:green}+1 overall{color}.  Here are the results of testing the latest attachment
  against trunk revision .

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+1 tests included{color}.  The patch appears to include 1 new or modified
test files.

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of
javac compiler warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase the total number
of release audit warnings.

    {color:green}+1 core tests{color}.  The patch passed unit tests in ambari-server.

Test results:
Console output:

This message is automatically generated.

> Alerts: Template Engine for Dispatching
> ---------------------------------------
>                 Key: AMBARI-8400
>                 URL:
>             Project: Ambari
>          Issue Type: Task
>          Components: alerts, ambari-server
>    Affects Versions: 2.0.0
>            Reporter: Jonathan Hurley
>            Assignee: Jonathan Hurley
>             Fix For: 2.0.0
>         Attachments: AMBARI-8400.patch
> Ambari's various dispatchers (such as Email and SNMP) can benefit from having a mechanism
where a template can be defined for the construction of notification data. This decouples
the content that Ambari is sending from the logic to compute the aggregate alerts.
> Apache Velocity is a good choice for this requirement as it includes a maturing template
language, VTL. 
> A single XML file that ships with Ambari will contain the default templates for known
alert target types. There will be an option to override the use of this file with a user-specified
location via In the event that a user-specific XML file cannot be parsed,
appropriate exceptions will be thrown, but the {{AlertNoticeDispatchService}} will attempt
to gracefully fallback on other content rendering options (such as the internal XML file).
> The following data should be exposed to VTL:
> - a list of all alert changes
> -- alert name, state, date, label
> -- a list for each state change
> -- lists for all alerts, broke down by service and state 
> - a list of all services with an alert
> - a list of all hosts with an alert
> - total counts of changes separated
> -- one count for each alert state

This message was sent by Atlassian JIRA

View raw message