You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Shuai Lin <li...@gmail.com> on 2016/03/04 09:58:56 UTC

Re: [jira] [Updated] (MESOS-3583) Introduce stream IDs in HTTP Scheduler API

If I understand it correctly, this change would break all existing
frameworks that use the http scheduler api, should we include a notice for
it in the release note?

On Fri, Mar 4, 2016 at 5:48 AM, Vinod Kone (JIRA) <ji...@apache.org> wrote:

>
>      [
> https://issues.apache.org/jira/browse/MESOS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> Vinod Kone updated MESOS-3583:
> ------------------------------
>     Fix Version/s: 0.28.0
>
> > Introduce stream IDs in HTTP Scheduler API
> > ------------------------------------------
> >
> >                 Key: MESOS-3583
> >                 URL: https://issues.apache.org/jira/browse/MESOS-3583
> >             Project: Mesos
> >          Issue Type: Task
> >            Reporter: Anand Mazumdar
> >            Assignee: Greg Mann
> >              Labels: mesosphere, tech-debt
> >             Fix For: 0.28.0
> >
> >
> > Currently, the HTTP Scheduler API has no concept of Sessions aka
> {{SessionID}} or a {{TokenID}}. This is useful in some failure scenarios.
> As of now, if a framework fails over and then subscribes again with the
> same {{FrameworkID}} with the {{force}} option set, the Mesos master would
> subscribe it.
> > If the previous instance of the framework/scheduler tries to send a Call
> , e.g. {{Call::KILL}} with the same previous {{FrameworkID}} set, it would
> be still accepted by the master leading to erroneously killing a task.
> > This is possible because we do not have a way currently of
> distinguishing connections. It used to work in the previous driver
> implementation due to the master also performing a {{UPID}} check to verify
> if they matched and only then allowing the call. Following the design
> process, we will implemented "stream IDs" for Mesos HTTP schedulers; each
> ID will be associated with a single subscription connection, and the
> scheduler must include it as a header in all non-subscribe calls sent to
> the master.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

Re: [jira] [Updated] (MESOS-3583) Introduce stream IDs in HTTP Scheduler API

Posted by Shuai Lin <li...@gmail.com>.
>
> Until we call them out as ready for production in a release, we are
> allowed to make breaking changes. This gives us flexibility to design and
> produce a better API.


Makes sense, thanks for the info!

On Sat, Mar 5, 2016 at 2:02 AM, Vinod Kone <vi...@apache.org> wrote:

> It was called out in the CHANGELOG under Additonal API Changes. Both the
> scheduler v1 API and executor v1 API are considered (and called out as)
> experimental. Until we call them out as ready for production in a release,
> we are allowed to make breaking changes. This gives us flexibility to
> design and produce a better API.
>
> On Fri, Mar 4, 2016 at 8:53 AM, Greg Mann <gr...@mesosphere.io> wrote:
>
>> I don't think there are currently any frameworks using the HTTP API? But
>> you have a good point, it's a breaking change to the API, so it's probably
>> worth calling it out prominently.
>>
>> On Fri, Mar 4, 2016 at 12:58 AM, Shuai Lin <li...@gmail.com>
>> wrote:
>>
>>> If I understand it correctly, this change would break all existing
>>> frameworks that use the http scheduler api, should we include a notice for
>>> it in the release note?
>>>
>>> On Fri, Mar 4, 2016 at 5:48 AM, Vinod Kone (JIRA) <ji...@apache.org>
>>> wrote:
>>>
>>>>
>>>>      [
>>>> https://issues.apache.org/jira/browse/MESOS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>>> ]
>>>>
>>>> Vinod Kone updated MESOS-3583:
>>>> ------------------------------
>>>>     Fix Version/s: 0.28.0
>>>>
>>>> > Introduce stream IDs in HTTP Scheduler API
>>>> > ------------------------------------------
>>>> >
>>>> >                 Key: MESOS-3583
>>>> >                 URL: https://issues.apache.org/jira/browse/MESOS-3583
>>>> >             Project: Mesos
>>>> >          Issue Type: Task
>>>> >            Reporter: Anand Mazumdar
>>>> >            Assignee: Greg Mann
>>>> >              Labels: mesosphere, tech-debt
>>>> >             Fix For: 0.28.0
>>>> >
>>>> >
>>>> > Currently, the HTTP Scheduler API has no concept of Sessions aka
>>>> {{SessionID}} or a {{TokenID}}. This is useful in some failure scenarios.
>>>> As of now, if a framework fails over and then subscribes again with the
>>>> same {{FrameworkID}} with the {{force}} option set, the Mesos master would
>>>> subscribe it.
>>>> > If the previous instance of the framework/scheduler tries to send a
>>>> Call , e.g. {{Call::KILL}} with the same previous {{FrameworkID}} set, it
>>>> would be still accepted by the master leading to erroneously killing a task.
>>>> > This is possible because we do not have a way currently of
>>>> distinguishing connections. It used to work in the previous driver
>>>> implementation due to the master also performing a {{UPID}} check to verify
>>>> if they matched and only then allowing the call. Following the design
>>>> process, we will implemented "stream IDs" for Mesos HTTP schedulers; each
>>>> ID will be associated with a single subscription connection, and the
>>>> scheduler must include it as a header in all non-subscribe calls sent to
>>>> the master.
>>>>
>>>>
>>>>
>>>> --
>>>> This message was sent by Atlassian JIRA
>>>> (v6.3.4#6332)
>>>>
>>>
>>>
>>
>

Re: [jira] [Updated] (MESOS-3583) Introduce stream IDs in HTTP Scheduler API

Posted by Vinod Kone <vi...@apache.org>.
It was called out in the CHANGELOG under Additonal API Changes. Both the
scheduler v1 API and executor v1 API are considered (and called out as)
experimental. Until we call them out as ready for production in a release,
we are allowed to make breaking changes. This gives us flexibility to
design and produce a better API.

On Fri, Mar 4, 2016 at 8:53 AM, Greg Mann <gr...@mesosphere.io> wrote:

> I don't think there are currently any frameworks using the HTTP API? But
> you have a good point, it's a breaking change to the API, so it's probably
> worth calling it out prominently.
>
> On Fri, Mar 4, 2016 at 12:58 AM, Shuai Lin <li...@gmail.com> wrote:
>
>> If I understand it correctly, this change would break all existing
>> frameworks that use the http scheduler api, should we include a notice for
>> it in the release note?
>>
>> On Fri, Mar 4, 2016 at 5:48 AM, Vinod Kone (JIRA) <ji...@apache.org>
>> wrote:
>>
>>>
>>>      [
>>> https://issues.apache.org/jira/browse/MESOS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>> ]
>>>
>>> Vinod Kone updated MESOS-3583:
>>> ------------------------------
>>>     Fix Version/s: 0.28.0
>>>
>>> > Introduce stream IDs in HTTP Scheduler API
>>> > ------------------------------------------
>>> >
>>> >                 Key: MESOS-3583
>>> >                 URL: https://issues.apache.org/jira/browse/MESOS-3583
>>> >             Project: Mesos
>>> >          Issue Type: Task
>>> >            Reporter: Anand Mazumdar
>>> >            Assignee: Greg Mann
>>> >              Labels: mesosphere, tech-debt
>>> >             Fix For: 0.28.0
>>> >
>>> >
>>> > Currently, the HTTP Scheduler API has no concept of Sessions aka
>>> {{SessionID}} or a {{TokenID}}. This is useful in some failure scenarios.
>>> As of now, if a framework fails over and then subscribes again with the
>>> same {{FrameworkID}} with the {{force}} option set, the Mesos master would
>>> subscribe it.
>>> > If the previous instance of the framework/scheduler tries to send a
>>> Call , e.g. {{Call::KILL}} with the same previous {{FrameworkID}} set, it
>>> would be still accepted by the master leading to erroneously killing a task.
>>> > This is possible because we do not have a way currently of
>>> distinguishing connections. It used to work in the previous driver
>>> implementation due to the master also performing a {{UPID}} check to verify
>>> if they matched and only then allowing the call. Following the design
>>> process, we will implemented "stream IDs" for Mesos HTTP schedulers; each
>>> ID will be associated with a single subscription connection, and the
>>> scheduler must include it as a header in all non-subscribe calls sent to
>>> the master.
>>>
>>>
>>>
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.3.4#6332)
>>>
>>
>>
>

Re: [jira] [Updated] (MESOS-3583) Introduce stream IDs in HTTP Scheduler API

Posted by Greg Mann <gr...@mesosphere.io>.
I don't think there are currently any frameworks using the HTTP API? But
you have a good point, it's a breaking change to the API, so it's probably
worth calling it out prominently.

On Fri, Mar 4, 2016 at 12:58 AM, Shuai Lin <li...@gmail.com> wrote:

> If I understand it correctly, this change would break all existing
> frameworks that use the http scheduler api, should we include a notice for
> it in the release note?
>
> On Fri, Mar 4, 2016 at 5:48 AM, Vinod Kone (JIRA) <ji...@apache.org> wrote:
>
>>
>>      [
>> https://issues.apache.org/jira/browse/MESOS-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Vinod Kone updated MESOS-3583:
>> ------------------------------
>>     Fix Version/s: 0.28.0
>>
>> > Introduce stream IDs in HTTP Scheduler API
>> > ------------------------------------------
>> >
>> >                 Key: MESOS-3583
>> >                 URL: https://issues.apache.org/jira/browse/MESOS-3583
>> >             Project: Mesos
>> >          Issue Type: Task
>> >            Reporter: Anand Mazumdar
>> >            Assignee: Greg Mann
>> >              Labels: mesosphere, tech-debt
>> >             Fix For: 0.28.0
>> >
>> >
>> > Currently, the HTTP Scheduler API has no concept of Sessions aka
>> {{SessionID}} or a {{TokenID}}. This is useful in some failure scenarios.
>> As of now, if a framework fails over and then subscribes again with the
>> same {{FrameworkID}} with the {{force}} option set, the Mesos master would
>> subscribe it.
>> > If the previous instance of the framework/scheduler tries to send a
>> Call , e.g. {{Call::KILL}} with the same previous {{FrameworkID}} set, it
>> would be still accepted by the master leading to erroneously killing a task.
>> > This is possible because we do not have a way currently of
>> distinguishing connections. It used to work in the previous driver
>> implementation due to the master also performing a {{UPID}} check to verify
>> if they matched and only then allowing the call. Following the design
>> process, we will implemented "stream IDs" for Mesos HTTP schedulers; each
>> ID will be associated with a single subscription connection, and the
>> scheduler must include it as a header in all non-subscribe calls sent to
>> the master.
>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.4#6332)
>>
>
>