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




src/main/java/org/apache/aurora/scheduler/http/LeaderHealth.java (line 49)
<https://reviews.apache.org/r/45511/#comment189387>

    Can we switch on this enum, rather than if/else branching? If we also add 
an explicit case for each enum value and reserve the default block for an 
unexpected status it will allow this code to continue to work as expected even 
if new values are added to the enum in the future (i.e. as things stand today, 
if we added a hypothetical state like `LeaderStatus.ALSO_LEADING`, it would 
fall into the `SERVICE_UNAVAILABLE` branch).


- Joshua Cohen


On March 31, 2016, 5:06 a.m., Ashwin Murthy wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45511/
> -----------------------------------------------------------
> 
> (Updated March 31, 2016, 5:06 a.m.)
> 
> 
> Review request for Aurora and Bill Farner.
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> AURORA-1493: create ELB-friendly endpoint to detect leading scheduler. The 
> fix is to add a new endpoint - "/leaderhealth" which returns http status code 
> 200 (OK) if the instance is the leader. If the instance is not the leader but 
> a leading exists, returns 500 (Internal server error). If there is no leader 
> at all, returns 503 (Service unavailable)
> 
> 
> Diffs
> -----
> 
>   src/main/java/org/apache/aurora/scheduler/http/LeaderHealth.java 
> PRE-CREATION 
>   src/test/java/org/apache/aurora/scheduler/http/LeaderHealthTest.java 
> PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/45511/diff/
> 
> 
> Testing
> -------
> 
> Added new unit test
> 
> 
> Thanks,
> 
> Ashwin Murthy
> 
>

Reply via email to