----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/31461/#review74283 -----------------------------------------------------------
Ship it! Ship It! - Tom Beerbower On Feb. 26, 2015, 4:43 a.m., Jonathan Hurley wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/31461/ > ----------------------------------------------------------- > > (Updated Feb. 26, 2015, 4:43 a.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 > >
