Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader

Thank you for popup this, have already mark it resolved. On Mon, May 2, 2016 at 4:32 AM, Marco Massenzio wrote: > Hi, > > sorry, I have not kept up with all the new endpoints :) > If there is already an endpoint (/redirect ?) that essentially addresses > the issue raised

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader

Hi, sorry, I have not kept up with all the new endpoints :) If there is already an endpoint (/redirect ?) that essentially addresses the issue raised by MESOS-3841 (https://issues.apache.org/jira/browse/MESOS-3841) then I'd suggest to close it and add a note. (I just saw it and thought it would

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader

Oh, @Marco. Thank you very much for your reply, vinodkone shepherd this and it have already submitted after other kindly guys reviews. For MESOS-3841, it should be resolved now because could get the leading master by "/redirect" endpoint. Do you have any concerns about it? I would like to solve

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader

@haosdent - thanks for doing this, very useful indeed! On a related issue [0], I'd like to that one on: - can anyone comment if that's a good idea/bad idea; and - would anyone be willing to shepherd it? Thanks! [0] Master HTTP API support to get the leader (

[Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader

Hi All, We intend to introduce a breaking change[1] in the http endpoints without the deprecation cycle. For below http endpoints, when user request to a master which is not a leader, user would get a 307 redirect(TEMPORARY_REDIRECT) to the leader master. * /create-volumes *

Re: [MESOS-1865] Redirect to the leader master when current master is not a leader.

Some feedback on this ticket: it focuses on the solution rather than the problem. We generally want to avoid this, I guess it's been coined 'The XY Problem' (thanks Benjamin Bannier). In this case it turns out that there are actually 2 distinct problems that the user is facing: (1) Passive

Re: [MESOS-1865] Redirect to the leader master when current master is not a leader.

+1 (my two cent is that the “correct” approach from an operations viewpoint is to first query for the leader, then ask the leader; shortcoming identified by Ben obvious, but possibly the lesser of the two evils - and probably unavoidable in a distributed systems without atomic transactions -

Re: [MESOS-1865] Redirect to the leader master when current master is not a leader.

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

Re: [MESOS-1865] Redirect to the leader master when current master is not a leader.

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

Re: [MESOS-1865] Redirect to the leader master when current master is not a leader.

Alright, let's revive it. I think we previously had problems trying to write a multi-master unit test. Might have to do some test infrastructure work to make that possible. On Wed, Jan 6, 2016 at 1:14 PM, Neil Conway wrote: > +1 -- I think we should make this change. The

Re: [MESOS-1865] Redirect to the leader master when current master is not a leader.

Regarding this issue, I see non-active marathon instance would proxy http requests to the active marathon instance. This way no matter which marathon instance the client is visiting, it would always get the correct result. Could we do the same with mesos masters? The implementation would be more

[MESOS-1865] Redirect to the leader master when current master is not a leader.

Hi, Adam and Haosdent Resurrecting this issue, https://issues.apache.org/jira/browse/MESOS-1865, I would like to make a +1 for this change, which apparently became cold but I think is very relevant and we had enough time to be prepared for a change like this, right? If necessary, can I help

Re: [MESOS-1865] Redirect to the leader master when current master is not a leader.

+1 -- I think we should make this change. The current behavior is quite dangerous. Neil On Wed, Jan 6, 2016 at 12:52 PM, Diogo Gomes wrote: > Hi, Adam and Haosdent > > > Resurrecting this issue, https://issues.apache.org/jira/browse/MESOS-1865, I > would like to make a +1

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader.

Hi Haosdent, Do you have a shepherd for this change? On 1 Jul 2015 8:06 am, Adam Bordelon a...@mesosphere.io wrote: The original ticket MESOS-1865 https://issues.apache.org/jira/browse/MESOS-1865 argues the point that requesting state data (e.g. tasks.json) from a non-leading master should

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader.

I'll volunteer to shepherd this, unless somebody else really wants to. I think returning any HTTP error code (other than 200 OK) would be preferable for those endpoints that would return empty data otherwise, but redirect is the most actionable one for getting to the real data. On Wed, Jul 1,

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader.

Sure, that makes sense. I guess I was wondering if we should document a recommended retry-limit threshold for people writing clients - along with a recommended approach for backing off before retrying again. On Wed, Jul 1, 2015 at 12:29 PM, haosdent haosd...@gmail.com wrote: Hi, @James Thank

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader.

Oh, I got it. I would discuss document this with @adam. Thank you for your great advice. On Thu, Jul 2, 2015 at 12:33 AM, James DeFelice james.defel...@gmail.com wrote: Sure, that makes sense. I guess I was wondering if we should document a recommended retry-limit threshold for people writing

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader.

Hi, @Tomas Senart. Currently, my patch is to redirect the request to correct url. For example: $ curl -i http://master1:5050/master/tasks.json HTTP/1.1 307 Temporary Redirect Date: Mon, 01 Jun 2015 06:30:08 GMT Location: http://master2:5050/master/tasks.json Content-Length: 0 Assume master1 is

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader.

In a cluster that's having network problems and the selected leader is flapping is there an upper limit on how many subsequent redirects a client may expect to receive before it should give up for some period of time? For example: client requests /tasks.json from master1 master1 sends redirect to

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader.

Hi, @James Thank you very much for your good question. My current patch could not avoid this problem. I think you could handle this in client side, give it up or return error when redirect times overflow your define limit. On Thu, Jul 2, 2015 at 12:23 AM, James DeFelice james.defel...@gmail.com

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader.

+1 As an API writer (and consumer), this behavior makes sense, and most clients (notably, Apache HttpClient) would be able to handle this transparently (I think - it's been a few years since I messed with it :) I completely agree that returning a 200 OK with empty (or, worse, stale) data would

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader.

The original ticket MESOS-1865 https://issues.apache.org/jira/browse/MESOS-1865 argues the point that requesting state data (e.g. tasks.json) from a non-leading master should not return 200 OK status code with empty data, as that is misleading. It should either return an error code, or valid data.

[Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader.

Hi All, We intend to introduce a breaking change[1] in the http endpoints. For below http endpoints, when user request to a master which is not a leader, user would got a 302 redirect to the leader master. * /slaves * /state * /stateSummary * /roles * /teardown * /tasks

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader.

Hi Haosdent, Thanks for the heads up. Would you be able to share the rationale for this change? Is it a precursor for something else? Best, Tomás On Tue 30 Jun 2015 at 19:24 haosdent haosd...@gmail.com wrote: Hi All, We intend to introduce a breaking change[1] in the http endpoints. For