aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <wfar...@apache.org>
Subject Re: Handling of aurora update when job/task cannot be scheduled
Date Tue, 20 May 2014 17:47:43 GMT
>
> 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 <mchucarroll@apache.org>wrote:

> On Tue, May 20, 2014 at 12:03 PM, Anindya Sinha <anindya.sinha@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message