Re: Review Request 58259: Add update affinity to Scheduler

> On April 19, 2017, 1 a.m., Santhosh Kumar Shanmugham wrote: > > src/main/java/org/apache/aurora/scheduler/updater/InstanceActionHandler.java > > Lines 98-106 (original), 100-108 (patched) > > > > > > In order to

Re: Review Request 57487: Implementation of Dynamic Reservations Proposal

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/57487/#review172435 --- Master (b847db8) is green with this patch.

Re: Review Request 57487: Implementation of Dynamic Reservations Proposal

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/57487/ --- (Updated April 20, 2017, 12:14 a.m.) Review request for Aurora, Mehrdad

Re: Review Request 58259: Add update affinity to Scheduler

> On April 19, 2017, 8 a.m., Santhosh Kumar Shanmugham wrote: > > src/main/java/org/apache/aurora/scheduler/state/TaskAssigner.java > > Lines 228-229 (patched) > > > > > > Should we check if the offer is already

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

> On April 19, 2017, 6:32 p.m., Stephan Erb wrote: > > I am not sure I understand your description. If you want faster updates, > > why don't you just reduce `watch_secs`? > > > > I understand `watch_secs` as the the time that we always wait _after_ we > > have entered `RUNNING`. So no task

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

> On April 19, 2017, 9:32 a.m., Stephan Erb wrote: > > I am not sure I understand your description. If you want faster updates, > > why don't you just reduce `watch_secs`? > > > > I understand `watch_secs` as the the time that we always wait _after_ we > > have entered `RUNNING`. So no task

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

> On April 19, 2017, 9:32 a.m., Stephan Erb wrote: > > I am not sure I understand your description. If you want faster updates, > > why don't you just reduce `watch_secs`? > > > > I understand `watch_secs` as the the time that we always wait _after_ we > > have entered `RUNNING`. So no task

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

> On April 19, 2017, 9:32 a.m., Stephan Erb wrote: > > I am not sure I understand your description. If you want faster updates, > > why don't you just reduce `watch_secs`? > > > > I understand `watch_secs` as the the time that we always wait _after_ we > > have entered `RUNNING`. So no task

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

> On April 19, 2017, 9:32 a.m., Stephan Erb wrote: > > I am not sure I understand your description. If you want faster updates, > > why don't you just reduce `watch_secs`? > > > > I understand `watch_secs` as the the time that we always wait _after_ we > > have entered `RUNNING`. So no task

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

> On April 19, 2017, 6:31 p.m., Zameer Manji wrote: > > "Without this tasks will wait for watch_secs after the task moves to > > RUNNING extending the update time." > > > > I thought this was intentional. One can use this parameter to naturally > > slow down update speed. I was under the

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58524/#review172358 --- Master (b847db8) is red with this patch.

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58524/#review172354 --- I am not sure I understand your description. If you want faster

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58524/#review172357 --- "Without this tasks will wait for watch_secs after the task moves

Re: Review Request 56935: Fix for unnecessary object serializations

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/56935/#review172352 --- Ship it! Ship It! - Santhosh Kumar Shanmugham On Feb. 22,

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58524/ --- (Updated April 19, 2017, 9:18 a.m.) Review request for Aurora, Joshua Cohen,

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58524/#review172348 --- Ship it! Ship It! - David McLaughlin On April 19, 2017,

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58524/#review172340 --- Ship it! lgtm

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58524/#review172332 --- @ReviewBot retry - Santhosh Kumar Shanmugham On April 19,

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

> On April 19, 2017, 2:12 a.m., Aurora ReviewBot wrote: > > Master (b847db8) is red with this patch. > > ./build-support/jenkins/build.sh > > > > :commons:classesThriftNote: Some input files use unchecked or unsafe > > operations. > > Note: Recompile with -Xlint:unchecked for details. > > >

Re: Review Request 58524: Allow task to be in STARTING state during watch_secs.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58524/#review172329 --- Master (b847db8) is red with this patch.

Review Request 58524: Allow task to be in STARTING state during watch_secs.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58524/ --- Review request for Aurora, Joshua Cohen, Stephan Erb, and Zameer Manji.

Re: Review Request 58462: Fix bug. Do not increase current_consecutive_successes if .healthchecksnooze present

> On April 14, 2017, 2:26 p.m., Santhosh Kumar Shanmugham wrote: > > src/main/python/apache/aurora/executor/common/health_checker.py > > Lines 163-166 (patched) > > > > > > This will cause a task to get stuck in

Re: Review Request 58259: Add update affinity to Scheduler

> On April 17, 2017, 1:27 p.m., Stephan Erb wrote: > > src/main/java/org/apache/aurora/scheduler/updater/UpdaterModule.java > > Lines 52-55 (patched) > > > > > > I am trying to understand if this is a good default

Re: Review Request 58259: Add update affinity to Scheduler

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58259/#review172324 --- I like the simplicity of the overall approach. We should take