Re: Propsal: Centralizing update orchestration in Aurora

Thanks for chiming in, everyone. We will be tracking the work with AURORA-610 [1]. [1] https://issues.apache.org/jira/browse/AURORA-610 -=Bill On Fri, Jul 25, 2014 at 6:18 PM, Maxim Khutornenko wrote: > Thanks for clarifying. Makes sense to me. > > On Fri, Jul 25, 2014 at 5:14 PM, Bill Far

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

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

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

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

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

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

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

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

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

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

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