> On March 31, 2016, 6:26 p.m., Bill Farner wrote: > > src/main/java/org/apache/aurora/scheduler/http/LeaderHealth.java, line 54 > > <https://reviews.apache.org/r/45511/diff/4/?file=1320481#file1320481line54> > > > > Is it useful to send a different status code for this state? Seems > > like it doesn't make a difference to a load balancer, and trying to > > differentiate forces use of an awkward code.
I thought about this and decided to go with different codes to disambiguate these two cases. My reasoning was If this endpoint ends up being used for other things like a canary monitoring the leader health and the different code could result in different action. Either way, not differentiating it seems like hiding this information which could be potentially useful in the future and I didnt see a good reason to hide it. > On March 31, 2016, 6:26 p.m., Bill Farner wrote: > > src/main/java/org/apache/aurora/scheduler/http/LeaderHealth.java, line 52 > > <https://reviews.apache.org/r/45511/diff/4/?file=1320481#file1320481line52> > > > > I'm not fond of a 500, as it's typically reserved for cases of genuine > > unknown error. 503 seems more appropriate if it's all the same. the RFC says 503 means "the service is having temporary issues and will be resolved soon, so please retry after some time" I feel this is more appropriate when there is no leader at all. If we agree it is ok to disambiguate no leader from the case where this instance is not the leader, 500 seemed the best option. - Ashwin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/45511/#review126383 ----------------------------------------------------------- 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 > >
