You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Hadoop QA (JIRA)" <ji...@apache.org> on 2016/04/04 23:40:25 UTC
[jira] [Commented] (AMBARI-15603) Exposure of Global Alert Repeat
Tolerance Value in Web Client
[ https://issues.apache.org/jira/browse/AMBARI-15603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15225107#comment-15225107 ]
Hadoop QA commented on AMBARI-15603:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12796871/AMBARI-15603.v0.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include any new or modified tests.
Please justify why no new tests are needed for this patch.
Also please list what manual steps were performed to verify this patch.
{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-web.
Test results: https://builds.apache.org/job/Ambari-trunk-test-patch/6185//testReport/
Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/6185//console
This message is automatically generated.
> Exposure of Global Alert Repeat Tolerance Value in Web Client
> -------------------------------------------------------------
>
> Key: AMBARI-15603
> URL: https://issues.apache.org/jira/browse/AMBARI-15603
> Project: Ambari
> Issue Type: Task
> Components: ambari-web
> Affects Versions: 2.4.0
> Reporter: Zhe (Joe) Wang
> Assignee: Zhe (Joe) Wang
> Fix For: 2.4.0
>
> Attachments: AMBARI-15603.v0.patch
>
>
> The global repeat tolerance value for all alert definitions is set on the cluster-env configuration. Unless an alert definition overrides this value, it will be used for any definition in the system. By default, this value will be set to 1, indicating that there is no tolerance and the alert state should be taken at face value.
> {code}
> GET api/v1/clusters/<cluster>/configurations?type=cluster-env&tag=<tag>
> "Config": {
> "cluster_name": "c1",
> "stack_id": "HDP-2.4"
> },
> "properties": {
> "command_retry_enabled": "true",
> "command_retry_max_time_in_sec": "600",
> ...
> "alerts_repeat_tolerance" : "1"
> ...
> }
> {code}
> The web client should expose a way to update the {{cluster-env}} to set this value.
> *UI Warning of Delayed Alerts*
> When changing the value of the global of definition-specific repeat tolerance, a warning should be presented to the user to indicate that it will now take longer for the alert notifications to be sent. This is because notifications are delayed until the interval multiplied by the repeat tolerance is reached. Consider the case where the check against an alert happens every 5 minutes and the repeat tolerance is set to 5. It will be at least 25 minutes before any outbound notifications are dispatched. This warning can be on a per-alert definition basis as well as when setting the global value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)