Paul/Aviv is this related to your guys work? Dan had to update chromite on the test servers to get past this eariler.

I'm guessing something broke but not sure why the CQ didn't block it.

Lgoodby what is your MobLab IP so we can poke around?

Yeah the builders are all green so somehow the automated catching isn't seeing this.

Problem is this is older moblab image testing new dut images. We need to try/except that import. I'll look at this in the morning.

Dan thoughts on having the SSP image include chromite?

It's possible, we can upgrade base image to include chromite. However, that means every time moblab include some new chromite with desired function, we will have to update base container.

I think it's better for chromite related code to maintain backwards compatibility. Especially in this case, metrics doesn't work for moblab anyway.

"I think it's better for chromite related code to maintain backwards compatibility."
The problem with this answer is how do we enforce it? We would need a common import strategy for chromite code that does not fail when modules are imported.

Maybe code that uses metrics should do so though an Autotest library that imports metrics?

I'd just like to point out that this is another problem that would go away with a proper build system & virtualenv instead of relying on dependencies already being on the system.

I'm seeing similar/same issue running 'atest host list'

Re c#9:  Try running 'update_lab_tools'.

that worked after I blew away src/aosp/toolchain/gcc which made git? angry for some reason.  Thanks!

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

commit 382506be44b6f3d7f3943ca299a371a94f0d4b3c
Author: Simran Basi <sbasi@google.com>
Date: Tue Sep 13 21:58:15 2016

cros_host: Fix metrics import for moblab.

BUG= chromium:646217 
TEST=None

Change-Id: Ieb05d058dbbddab7282cf0aec382504f5cc2aa2a
Reviewed-on: https://chromium-review.googlesource.com/385109
Commit-Ready: Simran Basi <sbasi@chromium.org>
Tested-by: Simran Basi <sbasi@chromium.org>
Reviewed-by: Aviv Keshet <akeshet@chromium.org>

[modify] https://crrev.com/382506be44b6f3d7f3943ca299a371a94f0d4b3c/server/hosts/cros_host.py

Also, hold on - this isn't a problem with *backwards* compatibility, it's a problem with *forwards* compatibility.  We added a module, and autotest code that expects that module to be there should be able to work (it doesn't).  The only sane way to maintain forwards compatibility is to add a wrapper in autotest that gracefully degrades when the features we added aren't there.

Yup its a forward compatibility problem. I don't understand your proposal though.