You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@ambari.apache.org by "Zhe (Joe) Wang" <jw...@hortonworks.com> on 2016/04/04 19:58:15 UTC

Review Request 45692: AMBARI-15603 Exposure of Global Alert Repeat Tolerance Value in Web Client

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45692/
-----------------------------------------------------------

Review request for Ambari, Alexandr Antonenko, Jaimin Jetly, Jonathan Hurley, Oleg Nechiporenko, Richard Zang, Srimanth Gunturi, Xi Wang, and Yusaku Sako.


Bugs: AMBARI-15603
    https://issues.apache.org/jira/browse/AMBARI-15603


Repository: ambari


Description
-------

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.

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"
       ...
      }

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.


Diffs
-----

  ambari-web/app/controllers/main/alerts/alert_definitions_actions_controller.js dc9f78c 
  ambari-web/app/messages.js 1b2a02f 
  ambari-web/app/styles/application.less a6b79ce 
  ambari-web/app/templates/common/modal_popups/prompt_popup.hbs 078cc65 

Diff: https://reviews.apache.org/r/45692/diff/


Testing
-------

Local ambari-web test passed.
25600 tests complete (23 seconds)
154 tests pending
Manual testing done.


Thanks,

Zhe (Joe) Wang


Re: Review Request 45692: AMBARI-15603 Exposure of Global Alert Repeat Tolerance Value in Web Client

Posted by "Zhe (Joe) Wang" <jw...@hortonworks.com>.

> On April 4, 2016, 8:35 p.m., Jaimin Jetly wrote:
> > This patch doesn't address newly installed cluster case but does not address upgrade scenario i.e introducing new cluster-env/alerts_repeat_tolerance property to the existing cluster on upgrade with stack default value.
> > If there is not task tracking this work please create one.
> 
> Jaimin Jetly wrote:
>     Typo in the above comment.
>     This patch *do* address newly installed cluster case but does not address upgrade scenario

Actually, BE should populate the initial value for newly installed or upgraded cluster. FE just handle the case that backend returns nothing, which should not really happen.


- Zhe (Joe)


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45692/#review126935
-----------------------------------------------------------


On April 4, 2016, 5:58 p.m., Zhe (Joe) Wang wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45692/
> -----------------------------------------------------------
> 
> (Updated April 4, 2016, 5:58 p.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko, Jaimin Jetly, Jonathan Hurley, Oleg Nechiporenko, Richard Zang, Srimanth Gunturi, Xi Wang, and Yusaku Sako.
> 
> 
> Bugs: AMBARI-15603
>     https://issues.apache.org/jira/browse/AMBARI-15603
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> 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.
> 
> 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"
>        ...
>       }
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   ambari-web/app/controllers/main/alerts/alert_definitions_actions_controller.js dc9f78c 
>   ambari-web/app/messages.js 1b2a02f 
>   ambari-web/app/styles/application.less a6b79ce 
>   ambari-web/app/templates/common/modal_popups/prompt_popup.hbs 078cc65 
> 
> Diff: https://reviews.apache.org/r/45692/diff/
> 
> 
> Testing
> -------
> 
> Local ambari-web test passed.
> 25600 tests complete (23 seconds)
> 154 tests pending
> Manual testing done.
> 
> 
> Thanks,
> 
> Zhe (Joe) Wang
> 
>


Re: Review Request 45692: AMBARI-15603 Exposure of Global Alert Repeat Tolerance Value in Web Client

Posted by Jaimin Jetly <ja...@hortonworks.com>.

> On April 4, 2016, 8:35 p.m., Jaimin Jetly wrote:
> > This patch doesn't address newly installed cluster case but does not address upgrade scenario i.e introducing new cluster-env/alerts_repeat_tolerance property to the existing cluster on upgrade with stack default value.
> > If there is not task tracking this work please create one.

Typo in the above comment.
This patch *do* address newly installed cluster case but does not address upgrade scenario


- Jaimin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45692/#review126935
-----------------------------------------------------------


On April 4, 2016, 5:58 p.m., Zhe (Joe) Wang wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45692/
> -----------------------------------------------------------
> 
> (Updated April 4, 2016, 5:58 p.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko, Jaimin Jetly, Jonathan Hurley, Oleg Nechiporenko, Richard Zang, Srimanth Gunturi, Xi Wang, and Yusaku Sako.
> 
> 
> Bugs: AMBARI-15603
>     https://issues.apache.org/jira/browse/AMBARI-15603
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> 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.
> 
> 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"
>        ...
>       }
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   ambari-web/app/controllers/main/alerts/alert_definitions_actions_controller.js dc9f78c 
>   ambari-web/app/messages.js 1b2a02f 
>   ambari-web/app/styles/application.less a6b79ce 
>   ambari-web/app/templates/common/modal_popups/prompt_popup.hbs 078cc65 
> 
> Diff: https://reviews.apache.org/r/45692/diff/
> 
> 
> Testing
> -------
> 
> Local ambari-web test passed.
> 25600 tests complete (23 seconds)
> 154 tests pending
> Manual testing done.
> 
> 
> Thanks,
> 
> Zhe (Joe) Wang
> 
>


Re: Review Request 45692: AMBARI-15603 Exposure of Global Alert Repeat Tolerance Value in Web Client

Posted by Jaimin Jetly <ja...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45692/#review126935
-----------------------------------------------------------


Ship it!




This patch doesn't address newly installed cluster case but does not address upgrade scenario i.e introducing new cluster-env/alerts_repeat_tolerance property to the existing cluster on upgrade with stack default value.
If there is not task tracking this work please create one.

- Jaimin Jetly


On April 4, 2016, 5:58 p.m., Zhe (Joe) Wang wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45692/
> -----------------------------------------------------------
> 
> (Updated April 4, 2016, 5:58 p.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko, Jaimin Jetly, Jonathan Hurley, Oleg Nechiporenko, Richard Zang, Srimanth Gunturi, Xi Wang, and Yusaku Sako.
> 
> 
> Bugs: AMBARI-15603
>     https://issues.apache.org/jira/browse/AMBARI-15603
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> 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.
> 
> 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"
>        ...
>       }
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   ambari-web/app/controllers/main/alerts/alert_definitions_actions_controller.js dc9f78c 
>   ambari-web/app/messages.js 1b2a02f 
>   ambari-web/app/styles/application.less a6b79ce 
>   ambari-web/app/templates/common/modal_popups/prompt_popup.hbs 078cc65 
> 
> Diff: https://reviews.apache.org/r/45692/diff/
> 
> 
> Testing
> -------
> 
> Local ambari-web test passed.
> 25600 tests complete (23 seconds)
> 154 tests pending
> Manual testing done.
> 
> 
> Thanks,
> 
> Zhe (Joe) Wang
> 
>


Re: Review Request 45692: AMBARI-15603 Exposure of Global Alert Repeat Tolerance Value in Web Client

Posted by "Zhe (Joe) Wang" <jw...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45692/
-----------------------------------------------------------

(Updated April 4, 2016, 10:09 p.m.)


Review request for Ambari, Alexandr Antonenko, Jaimin Jetly, Jonathan Hurley, Oleg Nechiporenko, Richard Zang, Srimanth Gunturi, Xi Wang, and Yusaku Sako.


Bugs: AMBARI-15603
    https://issues.apache.org/jira/browse/AMBARI-15603


Repository: ambari


Description
-------

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.

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"
       ...
      }

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.


Diffs (updated)
-----

  ambari-web/app/controllers/main/alerts/alert_definitions_actions_controller.js dc9f78c 
  ambari-web/app/messages.js 1b2a02f 
  ambari-web/app/styles/application.less a6b79ce 
  ambari-web/app/templates/common/modal_popups/prompt_popup.hbs 078cc65 

Diff: https://reviews.apache.org/r/45692/diff/


Testing
-------

Local ambari-web test passed.
25600 tests complete (23 seconds)
154 tests pending
Manual testing done.


Thanks,

Zhe (Joe) Wang


Re: Review Request 45692: AMBARI-15603 Exposure of Global Alert Repeat Tolerance Value in Web Client

Posted by Richard Zang <rz...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/45692/#review126937
-----------------------------------------------------------


Ship it!




Ship It!

- Richard Zang


On April 4, 2016, 5:58 p.m., Zhe (Joe) Wang wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45692/
> -----------------------------------------------------------
> 
> (Updated April 4, 2016, 5:58 p.m.)
> 
> 
> Review request for Ambari, Alexandr Antonenko, Jaimin Jetly, Jonathan Hurley, Oleg Nechiporenko, Richard Zang, Srimanth Gunturi, Xi Wang, and Yusaku Sako.
> 
> 
> Bugs: AMBARI-15603
>     https://issues.apache.org/jira/browse/AMBARI-15603
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> 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.
> 
> 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"
>        ...
>       }
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   ambari-web/app/controllers/main/alerts/alert_definitions_actions_controller.js dc9f78c 
>   ambari-web/app/messages.js 1b2a02f 
>   ambari-web/app/styles/application.less a6b79ce 
>   ambari-web/app/templates/common/modal_popups/prompt_popup.hbs 078cc65 
> 
> Diff: https://reviews.apache.org/r/45692/diff/
> 
> 
> Testing
> -------
> 
> Local ambari-web test passed.
> 25600 tests complete (23 seconds)
> 154 tests pending
> Manual testing done.
> 
> 
> Thanks,
> 
> Zhe (Joe) Wang
> 
>