New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 812714 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

Fix repair special task with respect to quick provisioning

Project Member Reported by davidri...@chromium.org, Feb 15 2018

Issue description

Repair jobs are currently using quick provisioning (see https://bugs.chromium.org/p/chromium/issues/detail?id=811568#c19 and https://bugs.chromium.org/p/chromium/issues/detail?id=812435#c9)

Quick provisioning artifacts are not being staged and this results in a failure and fall back to non-quick provisioning path.

Either:
1. Don't use quick provisioning for repair process.
2. Ensure that quick provisioning artifacts are staged prior to repair.

I'm leaning towards #1 for the time being, and potentially revisit when we're fully confident in quick provisioning.  Anyone have particular leanings either way?
 
Approach #1 makes sense to me.
Status: Assigned (was: Untriaged)
Components: -Infra>Client>ChromeOS Infra>Client>ChromeOS>Test
I'm actively in the process of refactoring provisioning code
generally (and CrosHost.machine_install() specifically).  The
outline of the intended changes is at go/provision-diagnosability.

I expect that as a side-effect of those changes, that repair and
provisioning will share staging code, at which point we'd switch
to quick provisioning for repair.

The final changes are as much as 2 or 3 weeks out.  IIUC, I believe
that the fix here is trivial, so I'm indifferent as to whether this
is done now or later, but I do expect that "later" will, in some sense,
be free.

Sign in to add a comment