On Tue, May 20, 2014 at 11:41 AM, Jay Buffington wrote:
> On Tue, May 20, 2014 at 9:14 AM, Mark Chu-Carroll >wrote:
>
> > I agree. At the moment, the update process is completely driven by the
> > client, which creates some odd usability issues.
>
>
>
> >
>
> If we ran updates primarily on the s
On Tue, May 20, 2014 at 9:14 AM, Mark Chu-Carroll wrote:
> I agree. At the moment, the update process is completely driven by the
> client, which creates some odd usability issues.
>
If we ran updates primarily on the server, they could be handled
> asynchronously or synchronously in a way con
>
> 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 wrote:
> On Tue, May 20,
On Tue, May 20, 2014 at 12:03 PM, Anindya Sinha 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 immedia
> >
> > When a aurora create is done and if one or more instances are in PENDING
> > state, those instances may never get scheduled for the reasons you
> > mentioned in point 1
>
> Fair point. However, creating a job with a large number of instances coming
> up all at the same time is undesirable d
>
> When a aurora create is done and if one or more instances are in PENDING
> state, those instances may never get scheduled for the reasons you
> mentioned in point 1
Fair point. However, creating a job with a large number of instances coming
up all at the same time is undesirable due to reasons
Hi
Thanks for your feedback. Really appreciate it.
My responses inline starting with [AS].
Thanks
Anindya
- The task in PENDING state might never get scheduled due to variety of
> reasons, e.g.: unsatisfied constraints, unreasonable resource requirements
> and etc. Furthermore, if the task even
Thanks for the proposal, Anindya. I do have some concerns about it though:
- The task in PENDING state might never get scheduled due to variety of
reasons, e.g.: unsatisfied constraints, unreasonable resource requirements
and etc. Furthermore, if the task eventually gets scheduled, it may never
re
