> > and there's no easy way to resume the interrupted operation.
It's a bug if the updater doesn't no-op through instances that have already been updated. This should be fast enough to effectively be a resume. -=Bill On Tue, May 20, 2014 at 9:14 AM, Mark Chu-Carroll <mchucarr...@apache.org>wrote: > On Tue, May 20, 2014 at 12:03 PM, Anindya Sinha <anindya.si...@gmail.com > >wrote: > > > > > > > > > > Currently, aurora create is asynchronous whereas aurora update is > > > > synchronous which is leading to an inconsistent behavior of how > > instances > > > > are scheduled in create vs update. > > > > > > I don't necessarily see the immediate benefits of having consistency > > here. > > > The 'aurora create' does not carry the same contractual guarantees as > > > 'aurora update' simply because its semantics does not imply service > > > interruption. BTW, there is a '--wait_until' option that you can > provide > > to > > > 'aurora create' to make it feel more synchronous. > > > > > > > [AS] Actually, I prefer the asynchronous nature of aurora create since > > actual scheduling is being handled by the infrastructure. This discussion > > is primarily aimed at providing an option to make aurora update > > asynchronous as well. > > > > I agree. At the moment, the update process is completely driven by the > client, which creates some odd usability issues. Aurora commands other than > update/restart are all completely server driven, with the state of the > operation existing on the server. But update, in particular, relies almost > entirely on client state. If, for some reason, a client gets interrupted, > the aurora job gets left in whatever state it was in, and there's no easy > way to resume the interrupted operation. > > If we ran updates primarily on the server, they could be handled > asynchronously or synchronously in a way consistent with create, by using > wait-until parameters. > > -Mark >
