> 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 should be in `STARTING` state when we > > are watching. The documentation seems to agree with that: `Minimum number > > of seconds a shard must remain in ```RUNNING``` state before considered a > > success (Default: 45)`. > > > > (I haven't looked into the code yet, but maybe you can clarify before I do). > > Santhosh Kumar Shanmugham wrote: > That was the intent initially. However we risk delaying all updates > without any changes to `watch_secs`. That is the main concern here. Let me > know if this will be a breaking for you. > > Zameer Manji wrote: > It's breaking for me. Instead can we just change the default value of > `watch_secs` to be 0?
That is possible. It just means its not an opt-in change anymore. - Santhosh Kumar ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58524/#review172354 ----------------------------------------------------------- On April 19, 2017, 9:18 a.m., Santhosh Kumar Shanmugham wrote: > > ----------------------------------------------------------- > 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, Stephan Erb, and Zameer Manji. > > > Repository: aurora > > > Description > ------- > > Tasks are gated on health-checks before they transistion into `RUNNING` > and hence it is possible for a task to stay in `STARTING` during the > watch duration of an instance's update. So include `STARTING` into the > possible states for a task when watching it after an update. Without > this tasks will wait for watch_secs after the task moves to RUNNING > extending the update time. > > > Diffs > ----- > > src/main/java/org/apache/aurora/scheduler/updater/InstanceUpdater.java > c129896d8cd54abd2634e2a339c27921042b0162 > src/main/java/org/apache/aurora/scheduler/updater/StateEvaluator.java > c95943d242dc2f539778bdc9e071f342005e8de3 > src/test/java/org/apache/aurora/scheduler/updater/InstanceUpdaterTest.java > df1f8394b824dbb7b2745fcccdab5adaafdf6e6c > src/test/java/org/apache/aurora/scheduler/updater/OneWayJobUpdaterTest.java > 32a8c89d3e71395696fc613da96b871330891c42 > > > Diff: https://reviews.apache.org/r/58524/diff/2/ > > > Testing > ------- > > ./build-support/jenkins/build.sh > ./src/test/sh/org/apache/aurora/e2e/test_end_to_end.sh > > > Thanks, > > Santhosh Kumar Shanmugham > >