aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sirois <john.sir...@gmail.com>
Subject Re: Propsal: Centralizing update orchestration in Aurora
Date Fri, 25 Jul 2014 18:56:36 GMT
Inline

On Fri, Jul 25, 2014 at 12:41 PM, 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)
>

Can the service just use the mesos core state abstraction?  That comes
along as a free dependency setting up an aurora cluster.


>   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
>

I assume 3 is a ~wash in terms of time with productionizing new scheduler
code.


> 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