I want to do a push today.
The most obvious culprit is https://chromium-review.googlesource.com/#/c/400618/ but I don't know why it is breaking.

Double checked that chromeos-drone2-staging.hot where this drone ran had the correct version of the autotest software.

+jrbarnette (Reviewer of the said CL): ayatane@ is out today, so adding you before I decide to revert this CL and try my luck. I'm not convinced this CL should be breaking anything. I tried to import the said modules locally at autotest cros/master, and it works. Dunno why it fails in that hostless job.

I agree that the problem must be that CL.  Reverting will
presumably fix it, although I can't say for sure, since I
don't fully understand the failure, either.

My first guess is that when all is said and done, SSP will
be found to be involved.  But, let's revert first, and ask
questions later.

It's a hostless job, which does not run with ssp.

Whatever the problem is, it's quite for real:

$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import common
>>> from server.cros.dynamic_suite import dynamic_suite
>>> print dynamic_suite.provision
<module 'autotest_lib.server.cros.provision' from '/usr/local/google/home/jrbarnette/repos/cros.lab/src/third_party/autotest/files/server/cros/provision.pyc'>
>>> print dynamic_suite.provision.NamespaceLabel
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'NamespaceLabel'

The code in #6 works fine for me. Is that a repo sync issue?

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

commit 2c7471d3ae15cfaf934467d7d144567f54d6cec0
Author: Prathmesh Prabhu <pprabhu@chromium.org>
Date: Tue Nov 15 20:19:57 2016

Revert "[autotest] Standardize label logic"

This reverts commit fda3e23ce60251c17bdc213d72b0b575251ea6d1.

Speculatively reverting to un-break push-to-prod

BUG= chromium:665538 
TEST=push-to-prod test passes (maybe?). This is a speculative revert.

Change-Id: Ia435c3e220ce0bd3fceabf786b685355bc0488d1
Reviewed-on: https://chromium-review.googlesource.com/411388
Reviewed-by: Prathmesh Prabhu <pprabhu@chromium.org>
Tested-by: Prathmesh Prabhu <pprabhu@chromium.org>

[modify] https://crrev.com/2c7471d3ae15cfaf934467d7d144567f54d6cec0/server/cros/dynamic_suite/dynamic_suite.py
[modify] https://crrev.com/2c7471d3ae15cfaf934467d7d144567f54d6cec0/site_utils/test_runner_utils.py
[modify] https://crrev.com/2c7471d3ae15cfaf934467d7d144567f54d6cec0/scheduler/prejob_task.py
[modify] https://crrev.com/2c7471d3ae15cfaf934467d7d144567f54d6cec0/server/hosts/cros_host.py
[delete] https://crrev.com/6ae02f0988f60b893b47a5059738060ca3773b02/server/cros/provision_unittest.py
[modify] https://crrev.com/2c7471d3ae15cfaf934467d7d144567f54d6cec0/server/cros/provision.py

I'm guessing it's some pyc issue, deleting all pyc in chromeos-drone2-staging:/usr/local/autotest, might just fix the issue.

In chromeos-drone2-staging, I moved server/cros/provision.pyc to /tmp, and the test passed. 

The CL is not the one to blame. It's reverted too early.

Re#10: As far as pushing to prod is concerned, it's entirely likely that this same failure will occur if I try to push to prod with the CL.
So reverting that CL, waiting for push test to succeed, and pushing to prod is a reasonable thing to do.

Now, there _is_ a bug either in the way provision.py is first imported (so that .pyc is not updated) or the way we run the push test (so that .pyc is not updated). We need to figure that out and fix that, BUT, revert-and-push-first seems like the right approach still to me.

This is no longer blocking test_push (because the CL was reverted).
ayatane@: Let me know if you need help trying to figure out why provision.pyc is not getting re-created on a push.