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
