aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <wfar...@apache.org>
Subject Re: Propsal: Centralizing update orchestration in Aurora
Date Fri, 25 Jul 2014 22:36:11 GMT
Yeah, absolutely - we will retain AURORA-383
<https://issues.apache.org/jira/browse/AURORA-383> for that.

-=Bill


On Fri, Jul 25, 2014 at 2:48 PM, Brian Wickman <wickman@apache.org> wrote:

> The scheduler API should know when jobs are locked, though, right?  That
> information could be made available to the UI.
>
>
> On Fri, Jul 25, 2014 at 2:40 PM, Bill Farner <wfarner@apache.org> wrote:
>
> > I think the current API primitives used for updates (kill, add) will
> > continue to make sense, so a client could implement updates that way.
> >  However, these will not appear as updates to the scheduler.
> >
> > -=Bill
> >
> >
> > On Fri, Jul 25, 2014 at 2:31 PM, Maxim Khutornenko <maxim@apache.org>
> > wrote:
> >
> > > Retaining client update algorithm would require extra work on the
> > scheduler
> > > side to satisfy visibility requirements Bill outlined above, which may
> > not
> > > worth the effort. That would also create ground for inconsistent update
> > > expectations and experience.
> > >
> > >
> > > On Fri, Jul 25, 2014 at 1:34 PM, Brian Wickman <wickman@apache.org>
> > wrote:
> > >
> > > > Will the API for client-side updates still exist?  Will the client
> > > continue
> > > > to have its own implementation of 'update' (or perhaps an 'update
> > > --local'
> > > > flag?)  The reason I ask is whether customers should continue to have
> > the
> > > > flexbility to implement their own update algorithms (e.g. 1% -> 10%
> ->
> > > 25%
> > > > -> 25% -> 25% -> rest.)
> > > >
> > > >
> > > > On Fri, Jul 25, 2014 at 11:41 AM, Bill Farner <wfarner@apache.org>
> > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Rolling updates of services is a crucial feature in Aurora. As
> such,
> > we
> > > > > want to take great care when changing its behavior. Today, Aurora
> > > > operates
> > > > > by delegating this functionality to the client (or any API client,
> > for
> > > > that
> > > > > matter). While this has provided a nice abstraction, it turns out
> > there
> > > > are
> > > > > some shortcomings with this approach:
> > > > >
> > > > >   1. Visibility: since the scheduler does not know about updates,
> it
> > > > cannot
> > > > > display useful information about an in-progress update
> > > > >   2. Visibility: for two users to diagnose a failed update, they
> must
> > > be
> > > > at
> > > > > the same terminal, or copy/paste terminal output
> > > > >   3. Usability: the scheduler has no means to show information
> about
> > > how
> > > > an
> > > > > application's packages or configuration changed over time
> > > > >   4. Usability: update orchestration in the client means a lost
> > > > connection
> > > > > to the scheduler halts an update
> > > > >
> > > > > Some of the above issues can be addressed by moving update
> > > orchestration
> > > > to
> > > > > a service external to the scheduler. At first glance, this approach
> > is
> > > > > attractive, as there is a firm separation of concerns. However,
> there
> > > > are a
> > > > > few pitfalls with this approach:
> > > > >
> > > > >   1. Usability: setup and maintenance of an aurora cluster becomes
> > even
> > > > > more complicated (additional service + storage system)
> > > > >   2. Usability: the user interface becomes more complicated to
> stitch
> > > > > together, as end-users really should only have to visit one website
> > to
> > > > view
> > > > > job information.
> > > > >   3. Complexity: implementing a new production-ready service from
> > > scratch
> > > > > will take a non-trivial amount of time
> > > > >
> > > > > With these issues in mind, I propose that the scheduler take over
> the
> > > > > responsibility of application update orchestration. This will allow
> > us
> > > to
> > > > > solve the current design shortcomings, without the pitfalls of the
> > > > separate
> > > > > service approach.
> > > > >
> > > > > I'm interested in thoughts others have on this. Does the reasoning
> > seem
> > > > > sound? Are there things i'm missing?
> > > > >
> > > > >
> > > > > -=Bill
> > > > >
> > > >
> > >
> >
>

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