You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Vinod Kone (JIRA)" <ji...@apache.org> on 2015/02/13 02:08:12 UTC

[jira] [Updated] (MESOS-1127) Implement the protobufs for the scheduler API

     [ https://issues.apache.org/jira/browse/MESOS-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vinod Kone updated MESOS-1127:
------------------------------
    Summary: Implement the protobufs for the scheduler API  (was: Expose lower-level scheduler/executor API)

I've changed the title of this ticket to only capture the scheduler side of things, because that has already landed.

That said, I would like to propose some (breaking) changes to this file in light of HTTP API. Breaking changes should be ok because no one is really using this API (we never announced it and we never release bindings).

--> Remove MasterInfo from Registered and Reregistered protobufs, because this is no longer relevant. Schedulers know who exactly they are connecting to.

--> Remove Reregistered protobuf (keep the REREGISTERED type). Scheduler already provides framework id so we don't need to send the id again. See above the reason for killing MasterInfo.

--> Remove the Error protobuf and type. We can use HTTP 4xx status code to convey this. The HTTP response body is just string.

--> Remove Request protobuf and type. We never implemented this and it's not even clear if it fits with the offer model. We can always add it later if we think it's useful.

[~benjaminhindman] Let me know what you think.






> Implement the protobufs for the scheduler API
> ---------------------------------------------
>
>                 Key: MESOS-1127
>                 URL: https://issues.apache.org/jira/browse/MESOS-1127
>             Project: Mesos
>          Issue Type: Task
>          Components: framework
>            Reporter: Benjamin Hindman
>            Assignee: Benjamin Hindman
>              Labels: twitter
>
> The default scheduler/executor interface and implementation in Mesos have a few drawbacks:
> (1) The interface is fairly high-level which makes it hard to do certain things, for example, handle events (callbacks) in batch. This can have a big impact on the performance of schedulers (for example, writing task updates that need to be persisted).
> (2) The implementation requires writing a lot of boilerplate JNI and native Python wrappers when adding additional API components.
> The plan is to provide a lower-level API that can easily be used to implement the higher-level API that is currently provided. This will also open the door to more easily building native-language Mesos libraries (i.e., not needing the C++ shim layer) and building new higher-level abstractions on top of the lower-level API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)