Return-Path: X-Original-To: apmail-aurora-dev-archive@minotaur.apache.org Delivered-To: apmail-aurora-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2CA3F115CB for ; Tue, 20 May 2014 21:15:29 +0000 (UTC) Received: (qmail 73916 invoked by uid 500); 20 May 2014 21:15:29 -0000 Delivered-To: apmail-aurora-dev-archive@aurora.apache.org Received: (qmail 73866 invoked by uid 500); 20 May 2014 21:15:29 -0000 Mailing-List: contact dev-help@aurora.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@aurora.incubator.apache.org Delivered-To: mailing list dev@aurora.incubator.apache.org Received: (qmail 73857 invoked by uid 99); 20 May 2014 21:15:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 May 2014 21:15:29 +0000 X-ASF-Spam-Status: No, hits=-1998.5 required=5.0 tests=ALL_TRUSTED,HTML_MESSAGE,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.3] (HELO mail.apache.org) (140.211.11.3) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 20 May 2014 21:15:27 +0000 Received: (qmail 73758 invoked by uid 99); 20 May 2014 21:15:04 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 May 2014 21:15:04 +0000 Received: from localhost (HELO mail-vc0-f182.google.com) (127.0.0.1) (smtp-auth username wfarner, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 May 2014 21:15:04 +0000 Received: by mail-vc0-f182.google.com with SMTP id la4so1418817vcb.27 for ; Tue, 20 May 2014 14:15:03 -0700 (PDT) X-Gm-Message-State: ALoCoQmEuHuMngxhVnbHJ5kArF5hwDiJPADTcmoq4dmJXAvspJhBJhSYtEIy6HYL7/8qmjusNYmV MIME-Version: 1.0 X-Received: by 10.220.167.198 with SMTP id r6mr3886470vcy.36.1400620503213; Tue, 20 May 2014 14:15:03 -0700 (PDT) Received: by 10.58.59.101 with HTTP; Tue, 20 May 2014 14:15:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 May 2014 14:15:03 -0700 Message-ID: Subject: Re: Handling of aurora update when job/task cannot be scheduled From: Bill Farner To: "dev@aurora.incubator.apache.org" Content-Type: multipart/alternative; boundary=001a11c2a6088f3d9a04f9db5f68 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c2a6088f3d9a04f9db5f68 Content-Type: text/plain; charset=UTF-8 On Tue, May 20, 2014 at 11:41 AM, Jay Buffington wrote: > On Tue, May 20, 2014 at 9:14 AM, Mark Chu-Carroll >wrote: > > > I agree. At the moment, the update process is completely driven by the > > client, which creates some odd usability issues. > > > > > > > If we ran updates primarily on the server, they could be handled > > asynchronously or synchronously in a way consistent with create, by using > > wait-until parameters. > > > > Why are updates driven by the client? > The long-term goal is not strictly to have *the* client drive updates, but *a* client. We wanted the scheduler API be generic enough such that clients can orchestrate updates in the way they see fit. Extracting the code and state associated with updates also allowed us to purge a lot of code [1] [2] and state (state that was prone to become stale when clients walked away mid-update) as well. [1] https://github.com/apache/incubator-aurora/commit/4d82efd3efa7b2d5e902fa48fda08028dcf2ae37 [2] https://github.com/apache/incubator-aurora/commit/ec15507256c29e06441e0c52ed0463399aeffc80 --001a11c2a6088f3d9a04f9db5f68--