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

2016-05-01 Thread haosdent 
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 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 have been useful, and fun to fix).
>
> --
> *Marco Massenzio*
> http://codetrips.com
>
> On Sat, Apr 30, 2016 at 9:24 PM, haosdent  wrote:
>
>> 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 your concerns.
>>
>> On Sun, May 1, 2016 at 12:12 PM, Marco Massenzio 
>> wrote:
>>
>>> @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 (
>>> https://issues.apache.org/jira/browse/MESOS-3841)
>>>
>>> --
>>> *Marco Massenzio*
>>> http://codetrips.com
>>>
>>> On Tue, Apr 19, 2016 at 12:34 AM, haosdent  wrote:
>>>
 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
 * /destroy-volumes
 * /frameworks
 * /reserve
 * /slaves
 * /quota
 * /weights
 * /state
 * /state.json
 * /state-summary
 * /tasks
 * /tasks.json
 * /roles
 * /roles.json
 * /teardown
 * /maintenance/schedule
 * /maintenance/status
 * /machine/down
 * /machine/up
 * /unreserve

 For other endpoints in master, the behaviour is not change.

 If your existing framework/tool relied on the old behaviour, I suggest
 to add a logic to handle 307 redirect response.
 Please let me know if you have any queries/concerns. Any comments will
 be appreciated.

 Links:
 [1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865

 --
 Best Regards,
 Haosdent Huang

>>>
>>>
>>
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>
>


-- 
Best Regards,
Haosdent Huang

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

2016-05-01 Thread Marco Massenzio 
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 have been useful, and fun to fix).

-- 
*Marco Massenzio*
http://codetrips.com

On Sat, Apr 30, 2016 at 9:24 PM, haosdent  wrote:

> 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 your concerns.
>
> On Sun, May 1, 2016 at 12:12 PM, Marco Massenzio 
> wrote:
>
>> @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 (
>> https://issues.apache.org/jira/browse/MESOS-3841)
>>
>> --
>> *Marco Massenzio*
>> http://codetrips.com
>>
>> On Tue, Apr 19, 2016 at 12:34 AM, haosdent  wrote:
>>
>>> 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
>>> * /destroy-volumes
>>> * /frameworks
>>> * /reserve
>>> * /slaves
>>> * /quota
>>> * /weights
>>> * /state
>>> * /state.json
>>> * /state-summary
>>> * /tasks
>>> * /tasks.json
>>> * /roles
>>> * /roles.json
>>> * /teardown
>>> * /maintenance/schedule
>>> * /maintenance/status
>>> * /machine/down
>>> * /machine/up
>>> * /unreserve
>>>
>>> For other endpoints in master, the behaviour is not change.
>>>
>>> If your existing framework/tool relied on the old behaviour, I suggest
>>> to add a logic to handle 307 redirect response.
>>> Please let me know if you have any queries/concerns. Any comments will
>>> be appreciated.
>>>
>>> Links:
>>> [1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865
>>>
>>> --
>>> Best Regards,
>>> Haosdent Huang
>>>
>>
>>
>
>
> --
> Best Regards,
> Haosdent Huang
>

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

2016-04-30 Thread haosdent 
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 your concerns.

On Sun, May 1, 2016 at 12:12 PM, Marco Massenzio 
wrote:

> @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 (
> https://issues.apache.org/jira/browse/MESOS-3841)
>
> --
> *Marco Massenzio*
> http://codetrips.com
>
> On Tue, Apr 19, 2016 at 12:34 AM, haosdent  wrote:
>
>> 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
>> * /destroy-volumes
>> * /frameworks
>> * /reserve
>> * /slaves
>> * /quota
>> * /weights
>> * /state
>> * /state.json
>> * /state-summary
>> * /tasks
>> * /tasks.json
>> * /roles
>> * /roles.json
>> * /teardown
>> * /maintenance/schedule
>> * /maintenance/status
>> * /machine/down
>> * /machine/up
>> * /unreserve
>>
>> For other endpoints in master, the behaviour is not change.
>>
>> If your existing framework/tool relied on the old behaviour, I suggest to
>> add a logic to handle 307 redirect response.
>> Please let me know if you have any queries/concerns. Any comments will be
>> appreciated.
>>
>> Links:
>> [1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865
>>
>> --
>> Best Regards,
>> Haosdent Huang
>>
>
>


-- 
Best Regards,
Haosdent Huang

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

2016-04-30 Thread Marco Massenzio 
@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 (
https://issues.apache.org/jira/browse/MESOS-3841)

-- 
*Marco Massenzio*
http://codetrips.com

On Tue, Apr 19, 2016 at 12:34 AM, haosdent  wrote:

> 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
> * /destroy-volumes
> * /frameworks
> * /reserve
> * /slaves
> * /quota
> * /weights
> * /state
> * /state.json
> * /state-summary
> * /tasks
> * /tasks.json
> * /roles
> * /roles.json
> * /teardown
> * /maintenance/schedule
> * /maintenance/status
> * /machine/down
> * /machine/up
> * /unreserve
>
> For other endpoints in master, the behaviour is not change.
>
> If your existing framework/tool relied on the old behaviour, I suggest to
> add a logic to handle 307 redirect response.
> Please let me know if you have any queries/concerns. Any comments will be
> appreciated.
>
> Links:
> [1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865
>
> --
> Best Regards,
> Haosdent Huang
>

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

2015-07-01 Thread Alex Rukletsov 
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
 not return 200 OK status code with empty data, as that is misleading. It
 should either return an error code, or valid data. A redirect response can
 be interpreted by the requester as an error (not the leading master), or
 used to request the valid data from the leading master.

 On Tue, Jun 30, 2015 at 9:12 PM, Tomás Senart to...@mesosphere.io wrote:

  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
   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
   For other endpoints in master, the behaviour is not change. If your
   existing framework relied on this behaviour, I suggest add a logic to
   handle 302 redirect response. Let me know if you have any
  queries/concerns.
   Thank you very much.
  
   Links:
   [1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865
  
  
   --
   Best Regards,
   Haosdent Huang

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

2015-07-01 Thread Adam Bordelon 
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, 2015 at 1:22 AM, Alex Rukletsov a...@mesosphere.com wrote:

 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
  not return 200 OK status code with empty data, as that is misleading. It
  should either return an error code, or valid data. A redirect response
 can
  be interpreted by the requester as an error (not the leading master),
 or
  used to request the valid data from the leading master.
 
  On Tue, Jun 30, 2015 at 9:12 PM, Tomás Senart to...@mesosphere.io
 wrote:
 
   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
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
For other endpoints in master, the behaviour is not change. If your
existing framework relied on this behaviour, I suggest add a logic to
handle 302 redirect response. Let me know if you have any
   queries/concerns.
Thank you very much.
   
Links:
[1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865
   
   
--
Best Regards,
Haosdent Huang

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

2015-07-01 Thread James DeFelice 
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 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
 wrote:

  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 master2
  master1 is elected as leader
  client requests /tasks.json from master2
  master2 redirects to master1
  master3 is elected as leader
  client requests /tasks.json from master1
  master1 redirects to master3
  ...
 
 
  On Wed, Jul 1, 2015 at 6:09 AM, haosdent haosd...@gmail.com wrote:
 
   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 not a leader, master 2 is the leader. When you send
  your
   request to master1, you could recieve the redirection to master2. And
 the
   location field in response headers also contains the correct url. And
  this
   is a single patch, not a precursor for something else. Also thanks the
  help
   from @adam and @alex. :-)
  
   On Wed, Jul 1, 2015 at 12:12 PM, Tomás Senart to...@mesosphere.io
  wrote:
  
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
 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
 For other endpoints in master, the behaviour is not change. If your
 existing framework relied on this behaviour, I suggest add a logic
 to
 handle 302 redirect response. Let me know if you have any
queries/concerns.
 Thank you very much.

 Links:
 [1]  Tracking JIRA:
 https://issues.apache.org/jira/browse/MESOS-1865


 --
 Best Regards,
 Haosdent Huang

   
  
  
  
   --
   Best Regards,
   Haosdent Huang
  
 
 
 
  --
  James DeFelice
  585.241.9488 (voice)
  650.649.6071 (fax)
 



 --
 Best Regards,
 Haosdent Huang




-- 
James DeFelice
585.241.9488 (voice)
650.649.6071 (fax)

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

2015-07-01 Thread haosdent 
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 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 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
  wrote:
 
   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 master2
   master1 is elected as leader
   client requests /tasks.json from master2
   master2 redirects to master1
   master3 is elected as leader
   client requests /tasks.json from master1
   master1 redirects to master3
   ...
  
  
   On Wed, Jul 1, 2015 at 6:09 AM, haosdent haosd...@gmail.com wrote:
  
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 not a leader, master 2 is the leader. When you send
   your
request to master1, you could recieve the redirection to master2. And
  the
location field in response headers also contains the correct url. And
   this
is a single patch, not a precursor for something else. Also thanks
 the
   help
from @adam and @alex. :-)
   
On Wed, Jul 1, 2015 at 12:12 PM, Tomás Senart to...@mesosphere.io
   wrote:
   
 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
  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
  For other endpoints in master, the behaviour is not change. If
 your
  existing framework relied on this behaviour, I suggest add a
 logic
  to
  handle 302 redirect response. Let me know if you have any
 queries/concerns.
  Thank you very much.
 
  Links:
  [1]  Tracking JIRA:
  https://issues.apache.org/jira/browse/MESOS-1865
 
 
  --
  Best Regards,
  Haosdent Huang
 

   
   
   
--
Best Regards,
Haosdent Huang
   
  
  
  
   --
   James DeFelice
   585.241.9488 (voice)
   650.649.6071 (fax)
  
 
 
 
  --
  Best Regards,
  Haosdent Huang
 



 --
 James DeFelice
 585.241.9488 (voice)
 650.649.6071 (fax)




-- 
Best Regards,
Haosdent Huang

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

2015-07-01 Thread haosdent 
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 not a leader, master 2 is the leader. When you send your
request to master1, you could recieve the redirection to master2. And the
location field in response headers also contains the correct url. And this
is a single patch, not a precursor for something else. Also thanks the help
from @adam and @alex. :-)

On Wed, Jul 1, 2015 at 12:12 PM, Tomás Senart to...@mesosphere.io wrote:

 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
  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
  For other endpoints in master, the behaviour is not change. If your
  existing framework relied on this behaviour, I suggest add a logic to
  handle 302 redirect response. Let me know if you have any
 queries/concerns.
  Thank you very much.
 
  Links:
  [1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865
 
 
  --
  Best Regards,
  Haosdent Huang
 




-- 
Best Regards,
Haosdent Huang

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

2015-07-01 Thread James DeFelice 
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 master2
master1 is elected as leader
client requests /tasks.json from master2
master2 redirects to master1
master3 is elected as leader
client requests /tasks.json from master1
master1 redirects to master3
...


On Wed, Jul 1, 2015 at 6:09 AM, haosdent haosd...@gmail.com wrote:

 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 not a leader, master 2 is the leader. When you send your
 request to master1, you could recieve the redirection to master2. And the
 location field in response headers also contains the correct url. And this
 is a single patch, not a precursor for something else. Also thanks the help
 from @adam and @alex. :-)

 On Wed, Jul 1, 2015 at 12:12 PM, Tomás Senart to...@mesosphere.io wrote:

  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
   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
   For other endpoints in master, the behaviour is not change. If your
   existing framework relied on this behaviour, I suggest add a logic to
   handle 302 redirect response. Let me know if you have any
  queries/concerns.
   Thank you very much.
  
   Links:
   [1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865
  
  
   --
   Best Regards,
   Haosdent Huang
  
 



 --
 Best Regards,
 Haosdent Huang




-- 
James DeFelice
585.241.9488 (voice)
650.649.6071 (fax)

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

2015-07-01 Thread haosdent 
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
wrote:

 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 master2
 master1 is elected as leader
 client requests /tasks.json from master2
 master2 redirects to master1
 master3 is elected as leader
 client requests /tasks.json from master1
 master1 redirects to master3
 ...


 On Wed, Jul 1, 2015 at 6:09 AM, haosdent haosd...@gmail.com wrote:

  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 not a leader, master 2 is the leader. When you send
 your
  request to master1, you could recieve the redirection to master2. And the
  location field in response headers also contains the correct url. And
 this
  is a single patch, not a precursor for something else. Also thanks the
 help
  from @adam and @alex. :-)
 
  On Wed, Jul 1, 2015 at 12:12 PM, Tomás Senart to...@mesosphere.io
 wrote:
 
   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
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
For other endpoints in master, the behaviour is not change. If your
existing framework relied on this behaviour, I suggest add a logic to
handle 302 redirect response. Let me know if you have any
   queries/concerns.
Thank you very much.
   
Links:
[1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865
   
   
--
Best Regards,
Haosdent Huang
   
  
 
 
 
  --
  Best Regards,
  Haosdent Huang
 



 --
 James DeFelice
 585.241.9488 (voice)
 650.649.6071 (fax)




-- 
Best Regards,
Haosdent Huang

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

2015-07-01 Thread Marco Massenzio 
+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 be confusing to most clients.

*Marco Massenzio*
*Distributed Systems Engineer*

On Wed, Jul 1, 2015 at 9:54 AM, haosdent haosd...@gmail.com wrote:

 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 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 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
   wrote:
  
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 master2
master1 is elected as leader
client requests /tasks.json from master2
master2 redirects to master1
master3 is elected as leader
client requests /tasks.json from master1
master1 redirects to master3
...
   
   
On Wed, Jul 1, 2015 at 6:09 AM, haosdent haosd...@gmail.com wrote:
   
 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 not a leader, master 2 is the leader. When you
 send
your
 request to master1, you could recieve the redirection to master2.
 And
   the
 location field in response headers also contains the correct url.
 And
this
 is a single patch, not a precursor for something else. Also thanks
  the
help
 from @adam and @alex. :-)

 On Wed, Jul 1, 2015 at 12:12 PM, Tomás Senart to...@mesosphere.io
 
wrote:

  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
   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
   For other endpoints in master, the behaviour is not change. If
  your
   existing framework relied on this behaviour, I suggest add a
  logic
   to
   handle 302 redirect response. Let me know if you have any
  queries/concerns.
   Thank you very much.
  
   Links:
   [1]  Tracking JIRA:
   https://issues.apache.org/jira/browse/MESOS-1865
  
  
   --
   Best Regards,
   Haosdent Huang
  
 



 --
 Best Regards,
 Haosdent Huang

   
   
   
--
James DeFelice
585.241.9488 (voice)
650.649.6071 (fax)
   
  
  
  
   --
   Best Regards,
   Haosdent Huang
  
 
 
 
  --
  James DeFelice
  585.241.9488 (voice)
  650.649.6071 (fax)
 



 --
 Best Regards,
 Haosdent Huang

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

2015-07-01 Thread Adam Bordelon 
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. A redirect response can
be interpreted by the requester as an error (not the leading master), or
used to request the valid data from the leading master.

On Tue, Jun 30, 2015 at 9:12 PM, Tomás Senart to...@mesosphere.io wrote:

 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
  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
  For other endpoints in master, the behaviour is not change. If your
  existing framework relied on this behaviour, I suggest add a logic to
  handle 302 redirect response. Let me know if you have any
 queries/concerns.
  Thank you very much.
 
  Links:
  [1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865
 
 
  --
  Best Regards,
  Haosdent Huang

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

2015-06-30 Thread Tomás Senart 
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
 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
 For other endpoints in master, the behaviour is not change. If your
 existing framework relied on this behaviour, I suggest add a logic to
 handle 302 redirect response. Let me know if you have any queries/concerns.
 Thank you very much.

 Links:
 [1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865


 --
 Best Regards,
 Haosdent Huang