jrbarnette@ thought that we were using the old repair flow. If we do, we'd not need any artifacts from the source build. Which is the Right Thing (TM).

So, jrbarnette@ is going to flip the switch back, to use the old provision flow.

FYI: An example failed repair job: https://pantheon.corp.google.com/storage/browser/chromeos-autotest-results/hosts/chromeos4-row10-rack9-host15/1468-repair/20170404125553/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/01d689a5f87b19f473ab517a7b167320ffdc80be

commit 01d689a5f87b19f473ab517a7b167320ffdc80be
Author: Richard Barnette <jrbarnette@chromium.org>
Date: Fri Apr 07 16:34:40 2017

[autotest] Don't use "install_by_devserver" for AU repair.

The machine_install_by_devserver() code flow relies on a working
stateful partition (with python, etc.).  Repair can't afford to
depend on that, so use the old AU flow that doesn't depend on
a working stateful.

BUG= chromium:709281 
TEST=None

Change-Id: I095594bf6b869cb17a0731b81c4be703f324d388
Reviewed-on: https://chromium-review.googlesource.com/470786
Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
Tested-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Richard Barnette <jrbarnette@google.com>

[modify] https://crrev.com/01d689a5f87b19f473ab517a7b167320ffdc80be/server/afe_utils.py

I thought it was a case that "python lib doesn't work" & "old package cannot be staged". But tried provision_by_devserver on this DUT (chromeos4-row10-rack9-host15) after stable_version is updated to "quawks-release/R58-9334.28.0". It's finished successfully. So failed to get a case.

That's because in the case of this board, newer python from quawks-release/R58-9334.28.0 works on the old build on the DUT (R54... something).

That's not always guaranteed. See gwendal's bug where this breaks.

https://pantheon.corp.google.com/storage/browser/chromeos-autotest-results/hosts/chromeos4-row10-rack9-host15/2359-repair/20170704133130/debug/

Repair failed by no 'stateful_update' script 

Could not find Chrome OS source location for stateful_update script at /usr/local/google/chromeos/src/platform/dev/stateful_update, falling back to chroot copy
Could not chroot stateful_update script (which is ;/usr/bin/stateful_update'), falling back on client copy.

new shard & test_shard doesn't have chromeos in /usr/local/google, so there's no '/usr/local/google/chromeos/src/platform/dev/stateful_update'.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/52161ac0c7ec44cfed08be3aea013f3e3658ec42

commit 52161ac0c7ec44cfed08be3aea013f3e3658ec42
Author: Xixuan Wu <xixuan@chromium.org>
Date: Fri Apr 07 21:54:12 2017

Revert "[autotest] Don't use "install_by_devserver" for AU repair."

This reverts commit 01d689a5f87b19f473ab517a7b167320ffdc80be.

old provision code flow cannot work in new shards (like chromeos-server102.mtv & test_shard).

BUG= chromium:709281 

Reason for revert: <INSERT REASONING HERE>

Original change's description:
> [autotest] Don't use "install_by_devserver" for AU repair.
> 
> The machine_install_by_devserver() code flow relies on a working
> stateful partition (with python, etc.).  Repair can't afford to
> depend on that, so use the old AU flow that doesn't depend on
> a working stateful.
> 
> BUG= chromium:709281 
> TEST=None
> 
> Change-Id: I095594bf6b869cb17a0731b81c4be703f324d388
> Reviewed-on: https://chromium-review.googlesource.com/470786
> Commit-Queue: Richard Barnette <jrbarnette@chromium.org>
> Tested-by: Richard Barnette <jrbarnette@chromium.org>
> Reviewed-by: Richard Barnette <jrbarnette@google.com>
> 

TBR=jrbarnette@chromium.org,jrbarnette@google.com,xixuan@chromium.org,pprabhu@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= chromium:709281 

Change-Id: I74430cbea7c7911b3e313cb352427341c6b22a07
Reviewed-on: https://chromium-review.googlesource.com/471873
Reviewed-by: Xixuan Wu <xixuan@chromium.org>
Commit-Queue: Xixuan Wu <xixuan@chromium.org>
Tested-by: Xixuan Wu <xixuan@chromium.org>

[modify] https://crrev.com/52161ac0c7ec44cfed08be3aea013f3e3658ec42/server/afe_utils.py

Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable?

If a fix is in active development, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'm not quite sure what this bug was ever about, but I do recall
it was for a problem that's now fixed.