mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Mahler <>
Subject Re: [MESOS-1865] Redirect to the leader master when current master is not a leader.
Date Sat, 09 Jan 2016 06:25:43 GMT
We should add the "who-is-the-current" leader informational endpoint
regardless of whether we do redirection, no?

Will it be clear which endpoints should redirect? Seems the redirection
approach, if we were to do it, needs to be specified explicitly by the
user. Otherwise it may be confusing for users that some endpoints redirect
and some do not.

On Fri, Jan 8, 2016 at 12:47 PM, Neil Conway <> wrote:

> On Fri, Jan 8, 2016 at 12:29 PM, Benjamin Mahler <>
> wrote:
> > (2) It is difficult to reliably obtain cluster state through the existing
> > endpoints. This one is less clear to me than the first problem. Here we
> > have to think through how we want users to be hitting state endpoints. Do
> > they hit all the masters and take the first valid response? Do they first
> > ask for the leader, then query the leader? Both of these have races (the
> > first case has an issue that the requests are not atomic, you may receive
> > two valid responses ; the second case the leader information may become
> > stale before the second request). Do we add redirects? Even redirects
> have
> > issues, there may be multiple redirects, there may be a redirect to a
> > master that is unable to redirect further (and so we haven't really
> solved
> > the race difficulties with redirects).
> I believe the proposed behavior is:
> * Clients can query any master
> * Endpoint queries against a non-leading master result in redirects to
> the current leader
> If the client follows a redirect to a different master, it may get
> redirected one or more times; it might also be unable to reach the
> current leader, or the queried master might be unable to determine the
> current leader. That seems like quite reasonable behavior to me,
> though (and technically I would argue that these situations aren't
> really "races" -- the client just needs to recognize that as in any
> distributed system, the information it observes might be stale).
> We could alternatively introduce a "who-is-the-current-leader"
> endpoint (which is something people have asked for [1]). As long as
> non-leading masters notify clients that they aren't talking to a
> leader (e.g., by returning a 403/503 error), that should also avoid
> races.
> Neil
> [1]

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