Closed Bug 879960 Opened 11 years ago Closed 11 years ago

(Ash) Talos getting ImportError

Categories

(Testing :: Talos, defect)

Product:
Testing
Component:
Talos
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jyeo, Unassigned)

Details

16:45:55     INFO - #####
16:45:55     INFO - ##### Running run-tests step.
16:45:55     INFO - #####
16:45:55     INFO - Running command: ['/Users/cltbld/talos-slave/test/build/venv/bin/python', '--version']
16:45:55     INFO - Copy/paste: /Users/cltbld/talos-slave/test/build/venv/bin/python --version
16:45:55     INFO -  Python 2.6.1
16:45:55     INFO - Return code: 0
16:45:55     INFO - Running command: ['/Users/cltbld/talos-slave/test/build/venv/bin/talos', '--noisy', '--debug', '-v', '--executablePath', '/Users/cltbld/talos-slave/test/build/application/FirefoxNightly.app/Contents/MacOS/firefox', '--title', 'talos-r4-snow-024', '--symbolsPath', 'http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/ash-macosx64/1370374156/firefox-24.0a1.en-US.mac.crashreporter-symbols.zip', '--activeTests', u'tdhtmlr:tresize', '--results_url', 'http://graphs.mozilla.org/server/collect.cgi', '--output', 'talos.yml', '--branchName', 'Ash', u'--mozAfterPaint', u'--filter', u'ignore_first:5', u'--filter', u'median', '--webServer', 'localhost'] in /Users/cltbld/talos-slave/test/build
16:45:55     INFO - Copy/paste: /Users/cltbld/talos-slave/test/build/venv/bin/talos --noisy --debug -v --executablePath /Users/cltbld/talos-slave/test/build/application/FirefoxNightly.app/Contents/MacOS/firefox --title talos-r4-snow-024 --symbolsPath http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/ash-macosx64/1370374156/firefox-24.0a1.en-US.mac.crashreporter-symbols.zip --activeTests tdhtmlr:tresize --results_url http://graphs.mozilla.org/server/collect.cgi --output talos.yml --branchName Ash --mozAfterPaint --filter ignore_first:5 --filter median --webServer localhost
16:45:55    ERROR -  Traceback (most recent call last):
16:45:55     INFO -    File "/Users/cltbld/talos-slave/test/build/venv/bin/talos", line 9, in <module>
16:45:55     INFO -      load_entry_point('talos==0.0', 'console_scripts', 'talos')()
16:45:55     INFO -    File "/Users/cltbld/talos-slave/test/build/venv/lib/python2.6/site-packages/distribute-0.6.14-py2.6.egg/pkg_resources.py", line 305, in load_entry_point
16:45:55     INFO -      return get_distribution(dist).load_entry_point(group, name)
16:45:55     INFO -    File "/Users/cltbld/talos-slave/test/build/venv/lib/python2.6/site-packages/distribute-0.6.14-py2.6.egg/pkg_resources.py", line 2244, in load_entry_point
16:45:55     INFO -      return ep.load()
16:45:55     INFO -    File "/Users/cltbld/talos-slave/test/build/venv/lib/python2.6/site-packages/distribute-0.6.14-py2.6.egg/pkg_resources.py", line 1954, in load
16:45:55     INFO -      entry = __import__(self.module_name, globals(),globals(), ['__name__'])
16:45:55     INFO -    File "/Users/cltbld/talos-slave/test/build/venv/lib/python2.6/site-packages/talos/run_tests.py", line 11, in <module>
16:45:55     INFO -      import PerfConfigurator
16:45:55     INFO -    File "/Users/cltbld/talos-slave/test/build/venv/lib/python2.6/site-packages/talos/PerfConfigurator.py", line 16, in <module>
16:45:55     INFO -      import utils
16:45:55     INFO -    File "/Users/cltbld/talos-slave/test/build/venv/lib/python2.6/site-packages/talos/utils.py", line 16, in <module>
16:45:55     INFO -      from mozlog import debug,info
16:45:55     INFO -  ImportError: cannot import name debug
16:45:55    ERROR - Return code: 1
(from: https://tbpl.mozilla.org/php/getParsedLog.php?id=23788317&tree=Ash&full=1)

OS: Snow Leopard mac
Talos version: 7d4ae29b7d1f

I'm guessing this is a python 2.6 issue. The snow leopard machines are the only machines that uses python 2.6 to execute talos.
I would guess so too.
I think it's a matter of time before we need py27 on there, so this may just force the issue.
Are windows clients running 2.7?  This could just be a python configuration issue.
(In reply to Joel Maher (:jmaher) from comment #2)
> Are windows clients running 2.7?

yep.
This caused the regression: http://hg.mozilla.org/build/talos/rev/ba0ef3d82bdb#l8.13

The snow leopard machines were working fine (with 4a0e7514c66c) until we introduced 7d4ae29b7d1f for the tp5o suite.
this is where we get debug from:
https://github.com/mozilla/mozbase/blob/master/mozlog/mozlog/logger.py#L10

I recall having to specifically call out 'from logging import debug' because it would fail on some platforms (while using talos.zip).  Right now this works on python 2.4->2.7.  Can you log into one of the osx machines and see if you have access to logging and logging.debug by hand?
(In reply to Joel Maher (:jmaher) from comment #5)
> Can you log into one of the osx machines and see
> if you have access to logging and logging.debug by hand?

The change was introduced a month ago (https://github.com/mozilla/mozbase/commit/11a5b6780a8cb66941814948bc17482c3663cede) but both pypi.python.org and puppetagain is hosting mozlog == 1.1 which was uploaded last year. This means that all our machines are still using the old code that doesn't explicitly calls out the names that it wants to export.
we should ensure the entire mozbase is updated to the latest bits
I was discussing this with aki recently.
What about if we had a script that mirrored whatever was on pypi for the mozbase packages?
Or a script that would regenerate new packages and put them on puppetagain as soon as a version bump happened?
Uploaded mozlog == 1.2 to puppetagain. Seeing greens for osx 10.6 on https://tbpl.mozilla.org/?tree=Ash&jobname=talos.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to Armen Zambrano G. [:armenzg] (Release Enginerring) from comment #8)
> I was discussing this with aki recently.
> What about if we had a script that mirrored whatever was on pypi for the
> mozbase packages?
> Or a script that would regenerate new packages and put them on puppetagain
> as soon as a version bump happened?

I think the direction we're moving in is away from using puppetagain packages, since updating those can cause unsheriffable failures; instead, we'd like to use in-tree mozbase packages.  We're doing this right now for B2G unittests; we can do it soon after for other unittests that already use mozharness, and we plan to do that for talos as part of mozharness talos.

So, I think it probably isn't worth the time to create a script to update puppetagain from pypi; but, if this keeps biting us in the intermim, we could certainly discuss it.
I am not clear how we can get packages from in tree for use by an out of tree harness?  If we had talos in tree, this would be easier because we could include it in tests.zip and have all the packages bundled together.  I have a feeling that I am overlooking something obvious however simple or small it is that would help me understand this better.
We talked about this in the mozharness meeting yesterday; the idea was that rel-eng would add tests.zip to the buildbot sendchange that kicks off a talos run, so the (to be written) mozharness talos script would have access to mozbase packages from that.

Ultimately, it doesn't matter whether a harness is in-tree or not; if it gets triggered to run on a particular build, we can access that build's tests.zip.
:jsyeo, regarding https://github.com/mozilla/mozbase/pull/48 , is that any longer needed? (looks like not?)  If so, could you please comment there to that effect? Thanks
(In reply to Jeff Hammel [:jhammel] from comment #13)
> :jsyeo, regarding https://github.com/mozilla/mozbase/pull/48 , is that any
> longer needed? (looks like not?)  If so, could you please comment there to
> that effect? Thanks

I thought the pull request is already closed?
You need to log in before you can comment on or make changes to this bug.