ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Speidel" <jspei...@hortonworks.com>
Subject Re: Review Request 29547: Alerts: Allow Ability To Test An AlertTarget Before Creating It
Date Mon, 05 Jan 2015 18:47:49 GMT


> On Jan. 5, 2015, 3:25 p.m., Tom Beerbower wrote:
> > A general question about this proposal... why couldn't the user create an alert
target in some "test" mode where the target is not really active until the user is satisfied
that the target is configured correctly?  At that point the user could flip the switch from
"test" to "active".  I think that the new resource that you are proposing gets created on
a POST then discarded right away (you can never GET it) which is not really in line with the
rest of the APIs.
> 
> Jonathan Hurley wrote:
>     I actually went back and forth over this as well. I thought that adding this logic
to the alert target resource provider didn't seem right as it was only to be used for validation
of a target's connection capability. The alert target resource provider should only really
be providing CRUD operations on a new or existing target. We didn't actually want a target
to be created. 
>     
>     Nate brought up the point that we could use a property on the POST to control this,
but it just feels like we'd be over-complicating the POST in that case. I dislike the idea
of a buried property altering the entire behavior of a REST method.
> 
> Tom Beerbower wrote:
>     Ok, I see.  I would still like to find a solution that is in line with existing APIs.
 The create blueprint API allows you to do ...
>     
>        POST blueprints/myBP?validate_topology={true/false}
>        
>     where if you specify validate_topology=true and the validation fails then the BP
is not created.  Could we do something along those lines for alert targets?

+1 for Tom's suggestion.


- John


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


On Jan. 5, 2015, 5:13 p.m., Yurii Shylov wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/29547/
> -----------------------------------------------------------
> 
> (Updated Jan. 5, 2015, 5:13 p.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Nate Cole, and Tom Beerbower.
> 
> 
> Bugs: AMBARI-8978
>     https://issues.apache.org/jira/browse/AMBARI-8978
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> During the cluster installation, the web client would like to be able to have the administrator
configure an alert target for use with that cluster. However, because there are many properties
that are used to successfully create an AlertTarget, it's likely that the settings originally
provided may not work.
> 
> For example, when creating an AlertTarget for SMTP, if the security or port are not valid
(or the SMTP server is restricting access to certain IP addresses) then the target won't be
able to properly use it.
> 
> We need to be able to allow an AlertTarget to be "tested" before actually creating it
in the system. 
> 
> I propose a new endpoint off of targets that can be used to POST to. The POST can contain
all of the alert properties that would normally be found on an AlertTarget. The difference
is that no target is created; instead a status is returned about whether the target works
(and why it doesn't if it failed).
> 
> I would suggest also altering the dispatcher interface to support a new method; something
like {{Dispatcher.testAlertTarget(...)}} which will simply exercise the properties of the
target to ensure a good connection.
> 
> 
> Diffs
> -----
> 
>   ambari-server/src/main/java/org/apache/ambari/server/api/resources/ResourceInstanceFactoryImpl.java
e55b2cb 
>   ambari-server/src/main/java/org/apache/ambari/server/api/services/AlertTargetValidationService.java
PRE-CREATION 
>   ambari-server/src/main/java/org/apache/ambari/server/controller/internal/AlertTargetValidationResourceProvider.java
PRE-CREATION 
>   ambari-server/src/main/java/org/apache/ambari/server/controller/internal/DefaultProviderModule.java
be2a9ad 
>   ambari-server/src/main/java/org/apache/ambari/server/controller/spi/Resource.java 89d6837

>   ambari-server/src/main/java/org/apache/ambari/server/notifications/NotificationDispatcher.java
d8c1fda 
>   ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/EmailDispatcher.java
289e594 
>   ambari-server/src/main/java/org/apache/ambari/server/notifications/dispatchers/SNMPDispatcher.java
6a14f1b 
>   ambari-server/src/main/java/org/apache/ambari/server/state/services/AlertNoticeDispatchService.java
626799a 
>   ambari-server/src/test/java/org/apache/ambari/server/controller/internal/AlertTargetValidationResourceProviderTest.java
PRE-CREATION 
>   ambari-server/src/test/java/org/apache/ambari/server/notifications/EmailDispatcherTest.java
c88427d 
>   ambari-server/src/test/java/org/apache/ambari/server/notifications/MockDispatcher.java
1dc7e2d 
>   ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/EmailDispatcherTest.java
PRE-CREATION 
>   ambari-server/src/test/java/org/apache/ambari/server/notifications/dispatchers/SNMPDispatcherTest.java
db4af1c 
>   ambari-server/src/test/java/org/apache/ambari/server/state/services/AlertNoticeDispatchServiceTest.java
1feb102 
> 
> Diff: https://reviews.apache.org/r/29547/diff/
> 
> 
> Testing
> -------
> 
> Results :
> 
> Tests run: 2486, Failures: 0, Errors: 0, Skipped: 13
> 
> 
> Thanks,
> 
> Yurii Shylov
> 
>


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