[ 
https://issues.apache.org/jira/browse/MESOS-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14485542#comment-14485542
 ] 

Alexander Rukletsov commented on MESOS-1127:
--------------------------------------------

Guys, I see your point in making {{SlaveID}} required in {{TaskStatus}} and it 
makes sense to me. But does this mean it should be required in reconciliation 
query and kill task request as well? Does marking {{SlaveID}} optional (or not 
having it there at all) preclude making it required in {{TaskStatus}}?

My understanding is that if the master knows {{TaskID}} it can always deduce 
{{SlaveID}}; if the task is unknown to the master, then the task is considered 
lost in all cases except when there are transitionary slaves, in which case 
decision is postponed. Having {{SlaveID}} in reconciliation query and kill task 
request *just* speeds up reconciliation for unknown—to he master—tasks. 
Therefore making {{SlaveID}} required feels too much for me. Maybe [~bmahler] 
can provide more background and validate my thoughts.

> 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: Vinod Kone
>              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)

Reply via email to