ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nate Cole" <nc...@hortonworks.com>
Subject Re: Review Request 31461: Store Configuration In Agent Memory For Alerts
Date Thu, 26 Feb 2015 15:52:30 GMT

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

Ship it!


Ship It!

- Nate Cole


On Feb. 25, 2015, 11:43 p.m., Jonathan Hurley wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31461/
> -----------------------------------------------------------
> 
> (Updated Feb. 25, 2015, 11:43 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Nate Cole, and Tom Beerbower.
> 
> 
> Bugs: AMBARI-9807
>     https://issues.apache.org/jira/browse/AMBARI-9807
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> https://issues.apache.org/jira/browse/AMBARI-8885 fixes a problem where agents required
a restart in order for the alert framework to pickup configuration changes.
> 
> Initially, alerts were designed so that they only received the parameters they requested.
A single alert definition might only need a couple of values (such as hdfs-site/foo) as opposed
to the entire configuration structure.
> 
> However, it seems like we're doing a lot of extra work to ensure that these values are
kept current; alert definitions need to be rescheduled when a configuration changes so that
its cached value can be updated.
> 
> It would be good to investigate (and implement if plausible) a way to store the entire
configuration structure in memory and have it accessible to alerts (and any other part of
the agent framework). This would allow us to:
> 
> - Remove the code that caches values in the alert jobs before they are schedule
> - Remove the code the restarts jobs on configuration changes
> - Have an up-to-date configuration structure that is easily accessible without the need
to parse any files on-disk
> 
> The major concern would be that keeping such a large structure in memory could cause
some kind of performance degradation or memory overhead that would be unacceptable.
> 
> 
> Diffs
> -----
> 
>   ambari-agent/src/main/python/ambari_agent/AlertSchedulerHandler.py ba25936 
>   ambari-agent/src/main/python/ambari_agent/ClusterConfiguration.py PRE-CREATION 
>   ambari-agent/src/main/python/ambari_agent/Controller.py 1bf2613 
>   ambari-agent/src/main/python/ambari_agent/alerts/base_alert.py 2f2c997 
>   ambari-agent/src/main/python/ambari_agent/alerts/port_alert.py bc2e554 
>   ambari-agent/src/main/python/ambari_agent/alerts/script_alert.py 8f24f62 
>   ambari-agent/src/main/python/ambari_agent/alerts/web_alert.py 8ee6606 
>   ambari-agent/src/test/python/ambari_agent/TestAlerts.py a04088a 
> 
> Diff: https://reviews.apache.org/r/31461/diff/
> 
> 
> Testing
> -------
> 
> [INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0 approved: 122
licence.
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 11.578 s
> [INFO] Finished at: 2015-02-25T23:32:58-05:00
> [INFO] Final Memory: 8M/81M
> [INFO] ------------------------------------------------------------------------
> 
> Additionally, I broke all of my alerts on purpose to cause them to go into CRITICAL/UNKNOWN.
After deploying the changes, all alerts came back online as expected.
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message