ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hurley" <jhur...@hortonworks.com>
Subject Review Request 28159: Alerts: Targets Should Support A Severity Level
Date Tue, 18 Nov 2014 05:34:31 GMT

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

Review request for Ambari, Alejandro Fernandez, Nate Cole, and Tom Beerbower.


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


Repository: ambari


Description
-------

Alert targets should have an optional field that represents the severity levels that they
care about. This will allow users to create different targets that are only alerted when an
alert's state has transitioned to their support criticality level. 

For example, a user may want to have 2 different email targets, "Tier-1 Support" and "Tier-2
Support" where T1 receives WARNINGs only and T2 receives CRITICALS and UNKNOWNS.

We will extend the AlertTarget resource to provide this extra option. It will be a list of
supported criticality levels. If an empty list is specified, all alert states will be accepted
for the target.

An example of creating a target that only cares about OK and WARNING states.
```
{
  "AlertTarget": {
    "name": "Administrators",
    "description": "The Admins",
    "notification_type": "EMAIL",
    "alert_states": ["OK", "WARNING"],
    "properties":{
      "foo": "bar",
      "foobar" : "baz"
    }
  }
}
```

There was a database design choice that I had to make WRT storing a Set of enumerations. JPA
actually has a mechanism for this, but since Ambari doesn't use JPA correctly, it involves
creating a new table by hand. The other options that I considered were:
- JSON or CSV string of the enumerations
- A bit representing the OR'd value
- A BLOB column that stored the serialized set

I chose the table since it allows us to leverage JPA for the persistence and retrieval while
preventing our providers or DAOs from needing specialized serialization logic.


Diffs
-----

  ambari-server/src/main/java/org/apache/ambari/server/controller/internal/AlertTargetResourceProvider.java
3029114 
  ambari-server/src/main/java/org/apache/ambari/server/events/listeners/AlertStateChangedListener.java
c42851b 
  ambari-server/src/main/java/org/apache/ambari/server/orm/entities/AlertTargetEntity.java
12c394d 
  ambari-server/src/main/java/org/apache/ambari/server/upgrade/UpgradeCatalog200.java 2cbf266

  ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql 4d15914 
  ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql e3ae87a 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql 0587232 
  ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql 5605d57 
  ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 79caca7 
  ambari-server/src/main/resources/Ambari-DDL-SQLServer-DROP.sql 7658b63 
  ambari-server/src/test/java/org/apache/ambari/server/controller/internal/AlertTargetResourceProviderTest.java
7a633e7 
  ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog200Test.java
be97222 

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


Testing
-------

mvn clean test and manual testing to ensure that the alert targets are skipped and no notices
are created.


Thanks,

Jonathan Hurley


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