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

Issue 825342 link

Starred by 3 users
Status: Assigned
Owner:
█ jrbarnette@chromium.org
Last visit > 30 days ago
Cc:
pboggini@chromium.org
englab-sys-cros@google.com
pprabhu@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature



Sign in to add a comment

Inventory shouldn't track locked DUTs awaiting replacement

Project Member Reported by haoweiw@google.com, Mar 23 2018 
DUTs are locked are still counting in repair list which could misleading the accuracy of repair count. 

Those DUTs should not be counted and listed.

Removing DUTs from AFE database can fully resolve this issue but most time is costly because,  Lab team keeps locked DUT's records in database is to benefits future replacement deployment. Instead of using full deployment process, click "reverify" or "repair" in AFE could quickly and easily deploy those new DUTs if records exist in DB.

Comment 1 by jrbarnette@chromium.org, Mar 23 2018

Cc: pprabhu@chromium.org
Labels: -Hardware-Lab
Owner: ----
Summary: Inventory shouldn't track locked DUTs awaiting replacement (was: DUTs in locked stage should not be counted in repair list)
We have to track locked DUTs somehow:  If a working DUT is left locked
too long, we need to be able to find that out and report it.

However, if a DUT has been locked because it's broken, then once a
replacement is requested, we do want to quit tracking it.

More to the point, currently, the inventory identifies DUTs in one of
these four states:
  * Working and able to run tests.
  * Failing repair.
  * Idle, presumably locked.
  * Stuck in a repair loop.

For this bug, we need to add a fifth state:
  * Broken hardware, replacement ordered.

Comment 2 by jrbarnette@chromium.org, Apr 10 2018

Cc: pboggini@chromium.org
Regarding states that we need to track, we're now up to six, really.
See bug 804625.

The six states to track (including the new one implied by this bug) are
these:
 W) Working and able to run tests.
 B) Failing repair.
 I) Idle but unlocked.
 R) Stuck in a repair loop.
 L) Locked (ideally, for some temporary condition)
 H) Broken hardware, replacement ordered.

As the code is currently written, state "H" will instead
wind up aliased to one of the other states (typically, "L").
We need some way to disambiguate.

Comment 3 by ayatane@chromium.org, May 10 2018

Components: -Infra>Client>ChromeOS Infra>Client>ChromeOS>Test
Owner: jrbarnette@chromium.org
Status: Assigned (was: Untriaged)
►

Sign in to add a comment