You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by haosdent <ha...@gmail.com> on 2015/07/01 04:24:41 UTC
[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
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.
Posted by Adam Bordelon <ad...@mesosphere.io>.
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 <al...@mesosphere.com> wrote:
> Hi Haosdent,
>
> Do you have a shepherd for this change?
> On 1 Jul 2015 8:06 am, "Adam Bordelon" <ad...@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 <ha...@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.
Posted by Alex Rukletsov <al...@mesosphere.com>.
Hi Haosdent,
Do you have a shepherd for this change?
On 1 Jul 2015 8:06 am, "Adam Bordelon" <ad...@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 <ha...@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.
Posted by Adam Bordelon <ad...@mesosphere.io>.
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 <ha...@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.
Posted by Marco Massenzio <ma...@mesosphere.io>.
+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 <ha...@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 <ja...@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 <ha...@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.defelice@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 <ha...@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 <tomas@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 <ha...@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.
Posted by haosdent <ha...@gmail.com>.
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 <ja...@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 <ha...@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.defelice@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 <ha...@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 <ha...@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.
Posted by James DeFelice <ja...@gmail.com>.
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 <ha...@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 <ja...@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 <ha...@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 <ha...@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.
Posted by haosdent <ha...@gmail.com>.
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 <ja...@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 <ha...@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 <ha...@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.
Posted by James DeFelice <ja...@gmail.com>.
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 <ha...@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 <ha...@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.
Posted by haosdent <ha...@gmail.com>.
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 <ha...@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.
Posted by Tomás Senart <to...@mesosphere.io>.
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 <ha...@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
>