> 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

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


- Ashwin


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


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