[
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)
