Good news - my email alerts work!
Bad news - I've just discovered a LAVA bug that was keep all our panda
jobs from running:
http://validation.linaro.org/lava-server/scheduler/job/40330/definition
This job basically has a bad "server" parameter for the
"submit_results_on_host" action. It causes the stack trace attached at
the bottom. And the scheduler will keep trying over and over to run this.
Its late and I must sleep, but can someone please take a look at this
and propose a fix ASAP?
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 525, in __bootstrap
self.__bootstrap_inner()
File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 505, in run
self.__target(*self.__args, **self.__kwargs)
--- <exception caught here> ---
File
"/srv/lava/.cache/eggs/Twisted-12.1.0-py2.7-linux-x86_64.egg/twisted/python/threadpool.py",
line 167, in _worker
result = context.call(ctx, function, *args, **kwargs)
File
"/srv/lava/.cache/eggs/Twisted-12.1.0-py2.7-linux-x86_64.egg/twisted/python/context.py",
line 118, in callWithContext
return self.currentContext().callWithContext(ctx, func, *args, **kw)
File
"/srv/lava/.cache/eggs/Twisted-12.1.0-py2.7-linux-x86_64.egg/twisted/python/context.py",
line 81, in callWithContext
return func(*args,**kw)
File
"/srv/lava/.cache/eggs/lava_scheduler-0.24-py2.7.egg/lava_scheduler_daemon/dbjobsource.py",
line 64, in wrapper
return func(*args, **kw)
File
"/srv/lava/.cache/eggs/lava_scheduler-0.24-py2.7.egg/lava_scheduler_daemon/dbjobsource.py",
line 211, in getJobForBoard_impl
json_data = self._get_json_data(job)
File
"/srv/lava/.cache/eggs/lava_scheduler-0.24-py2.7.egg/lava_scheduler_daemon/dbjobsource.py",
line 107, in _get_json_data
netloc = job.submitter.username + '@' + parsed.hostname
exceptions.TypeError: coercing to Unicode: need string or buffer,
NoneType found
Just the one:
----------------
snowball07
----------------
http://validation.linaro.org/lava-server/scheduler/job/40303
Timed out in booting the test image, but in an odd way. It issued the "mmc init" at the u-boot prompt, got a u-boot prompt back, and then timed out 5 minutes later without issuing the rest of the boot commands. Have put back online to retest. I'd suggest that rebooting the test image *might* have solved this. Either that, or a bug in LAVA has been unearthed.
Thanks
Dave
Hi all,
One overnight failure:
----------------
panda-es04
----------------
http://validation.linaro.org/lava-server/scheduler/job/40109
Failed to get into test image. Some sort of corruption. Went onto the board and booted test image again. It came up, and we got a command prompt, but it was still pretty flakey: https://pastebin.linaro.org/1129/
Although a reboot of the test image *might* have fixed this, it looks like either the test image was dodgy, or the board is genuinely failing. I've put back online to test.
Thanks
Dave
Hi Andy,
I would like to take the following items in a separate blue-print. I
would request you to create one for me and let me know.
<snip>
TODOS:
For new testdef format we need to think about including new things such as:
* meta-data: targetted for lava-android-test, lava-test, lava-test-shell
* meta-data: OS like ubuntu, android, oe
* meta-data: device-types like panda, origen, etc
* overall test description
* descriptions of test cases, maybe think about some type of nesting
logic for optional test cases
</snip>
Thank You.
--
Senthil Kumaran S
http://www.stylesen.org/http://www.sasenthilkumaran.com/
Hi all,
In order to fix the IP address pool issue on the lava cloud, I need to take the cloud offline for about 30 minutes. To give everyone chance, I'm scheduling to do this at 10:00UTC tomorrow (Tuesday).
If this is problematic, please let me know asap.
Thanks
Dave
