aurora-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashwin Murthy <ashwinmur...@gmail.com>
Subject Re: Review Request 45511: AURORA-1493: create ELB-friendly endpoint to detect leading scheduler
Date Fri, 01 Apr 2016 03:22:17 GMT


> On March 31, 2016, 11:17 a.m., Stephan Erb wrote:
> > I have no clue about AWS & ELB, so just a couple of notes from the sideline:
> > 
> > * The new feature should be listed in `RELEASE-NOTES.md`
> > * We have to figure out how to document that properly (beyond the release notes).
Right now this is only done within the code. For a project as large as Aurora, this basically
means the feature does not exist at all. 
> >     
> >     *  Option A: We create a new documentation page in `docs/operations` that document
endpoints.
> >     *  Option B: We make sure the feature is self-documenting. This would mean we
add it to the scheduler `index.html` and return a description of the feature in the response
text. This would then be equivalent in how we handle the `mname` and `stuctdump` endpoints
> 
> Ashwin Murthy wrote:
>     I will update the release-notes.md. Is there a recommendation on which of the two
options is the prefered way for documenting this feature/new endpoint? Both options seem to
suggest that not all endpoints are currently documented. If we go with option A, we will need
a separate JIRA ticket to move remaining endpoints to be documented here. I am fine either
way, just want to see if there is a preferance eitherway
> 
> Stephan Erb wrote:
>     I believe `Option A` would probably be the better one, as it can be found via google
:-)
>     
>     But let's wait what the others think.
> 
> Bill Farner wrote:
>     Just noting that A & B are not mutually exclusive - we _could_ have both with
great success!
>     
>     I think B is a nice suggestion.  A first-time operator is quite likely to land at
the HTTP root first and poke around.

I have taken option A and filed a JIRA task to add the other endpoints to this as well. The
JIRA task has been linked in the newly added document called endpoints.md. I would prefer
to do just option A since this seems very clear and is searchable. Option B seems like a nice
to have and not a must :). Let me know if you think otherwise.


- Ashwin


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


On April 1, 2016, 3:20 a.m., Ashwin Murthy wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45511/
> -----------------------------------------------------------
> 
> (Updated April 1, 2016, 3:20 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
> -----
> 
>   RELEASE-NOTES.md 6fc3afeb5a9e2f2c2ba944fbc6d611d3494eb779 
>   docs/operations/endpoints.md PRE-CREATION 
>   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
> 
>


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