> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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) <[email protected]> >>> 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) >>>> >>> >>> >> >
