> 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 > >
