This is an automatically generated e-mail. To reply, visit:

(Updated Aug. 12, 2015, 2:44 a.m.)

Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Jie Yu, Joris 
Van Remoortere, and Vinod Kone.


Discarded [r36987](https://reviews.apache.org/r/36987/) and rebased accordingly.

Bugs: MESOS-2600

Repository: mesos


This involved a lot more challenges than I anticipated, I've captured the 
various approaches and limitations and deal-breakers of those approaches here: 
[Master Endpoint Implementation 

Key points:

* This is a stop-gap solution until we shift the offer creation/management 
logic from the master to the allocator.
* `updateAvailable` and `updateSlave` are kept separate because
  (1) `updateAvailable` is allowed to fail whereas `updateSlave` must not.
  (2) `updateAvailable` returns a `Future` whereas `updateSlave` does not.
  (3) `updateAvailable` never leaves the allocator in an over-allocated state 
and must not, whereas `updateSlave` does, and can.
* The algorithm:
    * Initially, the master pessimistically assume that what seems like 
"available" resources will be gone.
      This is due to the race between the allocator scheduling an `allocate` 
call to itself vs master's
      `allocator->updateAvailable` invocation.
      As such, we first try to satisfy the request only with the offered 
    * We greedily rescind one offer at a time until we've rescinded 
sufficiently many offers.
      IMPORTANT: We perform `recoverResources(..., Filters())` which has a 
default `refuse_sec` of 5 seconds,
      rather than `recoverResources(..., None())` so that we can virtually 
always win the race against `allocate`.
      In the rare case that we do lose, no disaster occurs. We simply fail to 
satisfy the request.
    * If we still don't have enough resources after resciding all offers, be 
semi-optimistic and forward the
      request to the allocator since there may be available resources to 
satisfy the request.
    * If the allocator returns a failure, report the error to the user with 

This approach is clearly not ideal, since we would prefer to rescind as little 
offers as possible.

Diffs (updated)

  src/master/http.cpp 7c650555ed15d310ad28e68239cbd56580fbae37 
  src/master/master.hpp bb7c8e9e05be829a6b9aa3100a714b2359854d96 
  src/master/master.cpp 398203d9367f85340166e66ecc34b9a33dd81048 
  src/master/validation.hpp 43b8d84556e7f0a891dddf6185bbce7ca50b360a 
  src/master/validation.cpp ffb7bf07b8a40d6e14f922eabcf46045462498b5 

Diff: https://reviews.apache.org/r/35702/diff/


`make check`


Michael Park

Reply via email to