From reviews-return-5194-apmail-mesos-reviews-archive=mesos.apache.org@mesos.apache.org Thu Jul 16 14:54:40 2015 Return-Path: X-Original-To: apmail-mesos-reviews-archive@minotaur.apache.org Delivered-To: apmail-mesos-reviews-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B06F3182AF for ; Thu, 16 Jul 2015 14:54:40 +0000 (UTC) Received: (qmail 31592 invoked by uid 500); 16 Jul 2015 14:54:28 -0000 Delivered-To: apmail-mesos-reviews-archive@mesos.apache.org Received: (qmail 31573 invoked by uid 500); 16 Jul 2015 14:54:28 -0000 Mailing-List: contact reviews-help@mesos.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: reviews@mesos.apache.org Delivered-To: mailing list reviews@mesos.apache.org Received: (qmail 31543 invoked by uid 99); 16 Jul 2015 14:54:27 -0000 Received: from reviews-vm.apache.org (HELO reviews.apache.org) (140.211.11.40) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Jul 2015 14:54:27 +0000 Received: from reviews.apache.org (localhost [127.0.0.1]) by reviews.apache.org (Postfix) with ESMTP id A532C1D4394; Thu, 16 Jul 2015 14:54:26 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============4162514533273411445==" MIME-Version: 1.0 Subject: Re: Review Request 35702: Added /reserve HTTP endpoint to the master. From: "Alexander Rukletsov" To: "Adam B" , "Benjamin Hindman" , "Jie Yu" , "Joris Van Remoortere" , "Vinod Kone" , "Ben Mahler" Cc: "mesos" , "Michael Park" , "Alexander Rukletsov" Date: Thu, 16 Jul 2015 14:54:26 -0000 Message-ID: <20150716145426.17362.69788@reviews.apache.org> X-ReviewBoard-URL: https://reviews.apache.org/ Auto-Submitted: auto-generated Sender: "Alexander Rukletsov" X-ReviewGroup: mesos X-Auto-Response-Suppress: DR, RN, OOF, AutoReply X-ReviewRequest-URL: https://reviews.apache.org/r/35702/ X-Sender: "Alexander Rukletsov" References: <20150628083643.13308.13356@reviews.apache.org> In-Reply-To: <20150628083643.13308.13356@reviews.apache.org> Reply-To: "Alexander Rukletsov" X-ReviewRequest-Repository: mesos --===============4162514533273411445== MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/35702/#review91889 ----------------------------------------------------------- src/master/http.cpp (line 447) Not directly related to endpoints, but to dynamic reservations in general. Do you think it makes sense to bookkeep dynamic reservation or have an aggregating method in `mesos::internal::master::Role`? - Alexander Rukletsov On June 28, 2015, 8:36 a.m., Michael Park wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/35702/ > ----------------------------------------------------------- > > (Updated June 28, 2015, 8:36 a.m.) > > > Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Jie Yu, Joris Van Remoortere, and Vinod Kone. > > > Bugs: MESOS-2600 > https://issues.apache.org/jira/browse/MESOS-2600 > > > Repository: mesos > > > Description > ------- > > 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 Challenges](https://docs.google.com/document/d/1cwVz4aKiCYP9Y4MOwHYZkyaiuEv7fArCye-vPvB2lAI/edit#) > > 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 resources. > * We greedily rescind one offer at a time until we've rescinded sufficiently many offers. > IMPORTANT: We perform `recoverResources(..., Filters())` rather than `recoverResources(..., None())` so that we can pretty much always win the race against `allocate`. > In the case that we lose, no disaster occurs. We simply fail to satisfy the request. > * If we still don't have enough resources after resciding all offers, be 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 `PreconditionFailed`. This could be updated to be `Forbidden`, or `Conflict` maybe as well. We'll pick one eventually. > > This approach is clearly not ideal, since we would prefer to rescind as little offers as possible. > The challenges of implementing the ideal solution in the current state is described in the document above. > > TODO(mpark): Add more comments and test cases. > > > Diffs > ----- > > src/master/http.cpp 350383362311cfbc830965e1155a8515f0dfb332 > src/master/master.hpp af83d3e82d2c161b3cc4583e78a8cbbd2f9a4064 > src/master/master.cpp 0782b543b451921d2240958c7ef612a9e30972df > src/master/validation.hpp 469d6f56c3de28a34177124aae81ce24cb4ad160 > src/master/validation.cpp 9d128aa1b349b018b8e4a1916434d848761ca051 > > Diff: https://reviews.apache.org/r/35702/diff/ > > > Testing > ------- > > `make check` > > > Thanks, > > Michael Park > > --===============4162514533273411445==--