> 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? > > Santhosh Kumar Shanmugham wrote: > That is possible. It just means its not an opt-in change anymore.
I'm ok to change the defaults and have our upgrades wildly fast by default. Users can tweak health checks to have slower upgrades and only use this parameter to have a fixed amount of time after an instance. This value is the most brittle and imprecise. - Zameer ----------------------------------------------------------- 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 > >
