Thanks for clarifying. Makes sense to me.
On Fri, Jul 25, 2014 at 5:14 PM, Bill Farner <wfar...@apache.org> 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 at 3:54 PM, Maxim Khutornenko <ma...@apache.org> wrote: > >> 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 <wfar...@apache.org> wrote: >> > 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 <wick...@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 <wfar...@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 <ma...@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 <wick...@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 <wfar...@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 >> >> > > > > >> >> > > > >> >> > > >> >> > >> >> >>
