aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <wfar...@apache.org>
Subject Re: Handling of aurora update when job/task cannot be scheduled
Date Tue, 20 May 2014 21:15:03 GMT
On Tue, May 20, 2014 at 11:41 AM, Jay Buffington <me@jaybuff.com> wrote:

> On Tue, May 20, 2014 at 9:14 AM, Mark Chu-Carroll <mchucarroll@apache.org
> >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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message