Re: [VOTE] Release Apache Aurora 0.5.0 (incubating) RC2

Justin I've created AURORA-600 [1] and have a patch up for review for it [2]. Running through the check list and everything else looks good +1 from me for 0.5.0-RC2 -Jake Apache Aurora 0.5.0-RC1 checklist - 1.1 Checksums and PGP signatures are valid. - checksum hashes match - signature ver

Propsal: Centralizing update orchestration in Aurora

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 t

Re: Propsal: Centralizing update orchestration in Aurora

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

Re: [VOTE] Release Apache Aurora 0.5.0 (incubating) RC2

Notice and license looks good Hashes and signatures are good Compiled +1 On Thursday, July 24, 2014, Kevin Sweeney wrote: > All, > I propose that we accept the following release candidate as the official > Apache Aurora 0.5.0 release. > > > Aurora 0.5.0-rc2 includes the following: > --- > The C

Re: Propsal: Centralizing update orchestration in Aurora

> > Can the service just use the mesos core state abstraction? That comes > along as a free dependency setting up an aurora cluster. If we take the separate service approach, i probably would not use the replicated log. In the scheduler, we're already contemplating moving away from it due to th

Re: Propsal: Centralizing update orchestration in Aurora

Possible pros to having the scheduler do the updates: - Scheduler likely has the most direct information with respect to job/task SLA style metrics, and can use these to help in keeping jobs within SLA during an update. - If the updates are given as "rate of change", if/when tasks fail in large

Re: Propsal: Centralizing update orchestration in Aurora

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%

Re: Propsal: Centralizing update orchestration in Aurora

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 Wickma

Re: Propsal: Centralizing update orchestration in Aurora

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 wrote: > Retaining client update alg

Re: Propsal: Centralizing update orchestration in Aurora

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 wrote: > I think the current API primitives used for updates (kill, add) will > continue to make sense, so a client could implemen

Re: Propsal: Centralizing update orchestration in Aurora

Yeah, absolutely - we will retain AURORA-383 for that. -=Bill On Fri, Jul 25, 2014 at 2:48 PM, Brian Wickman wrote: > The scheduler API should know when jobs are locked, though, right? That > information could be made available to the UI. > >

Re: Propsal: Centralizing update orchestration in Aurora

I am a bit confused. Are you suggesting we retain the current client updater algorithm or only the scheduler primitives it currently employs? On Fri, Jul 25, 2014 at 3:36 PM, Bill Farner wrote: > Yeah, absolutely - we will retain AURORA-383 > for

Re: Propsal: Centralizing update orchestration in Aurora

Only the API methods on the scheudler; i propose that the client adopt the scheduler's update orchestration and we delete the equivalent code from the client. -=Bill On Fri, Jul 25, 2014 at 3:54 PM, Maxim Khutornenko wrote: > I am a bit confused. Are you suggesting we retain the current client

Re: Propsal: Centralizing update orchestration in Aurora

Thanks for clarifying. Makes sense to me. On Fri, Jul 25, 2014 at 5:14 PM, Bill Farner wrote: > Only the API methods on the scheudler; i propose that the client adopt the > scheduler's update orchestration and we delete the equivalent code from the > client. > > -=Bill > > > On Fri, Jul 25, 2014