Uploaded image for project: 'Mesos'
  1. Mesos
  2. MESOS-810

New Scheduler API



    • Story
    • Status: Resolved
    • Major
    • Resolution: Incomplete
    • None
    • None
    • c++ api, java api, python api
    • None


      This ticket is an effort to capture requirements and link to related tickets for the future version of the Scheduler API. We should split these out as needed but for now I'll just document things off the top of my head:

      1. Batch status update acknowledgements. The current mechanism for acknowledging a status update is for the call to Scheduler::statusUpdate to return. At this point we send an acknowledgement to the slave. This simplistic approach forces schedulers to serially persist status updates if operating in a stateful manner, ultimately leading to scaling issues.

      2. Explicit behavior. By this I mean that when a Scheduler calls something like killTask, we'll currently implicitly drop it when we're disconnected from the Master. Rather than implicitly doing this, we either need to deliver things reliably or inform schedulers when their request was dropped. Returning Futures could be very powerful here.

      3. Statefulness and access to state. The scheduler driver is currently stateless (no persistence). This means schedulers currently have to persist state using our State abstraction or the replicated log, or through their own persistence mechanism. Providing a stateful scheduler driver increases the simplicity of framework schedulers substantially, and providing access to state makes it very simple to implement a framework.


        Issue Links



              Unassigned Unassigned
              bmahler Benjamin Mahler
              1 Vote for this issue
              9 Start watching this issue