linaro-validation

linaro-validation@lists.linaro.org

818 discussions

Re: [Linaro-validation] Panda ES (4460) for LAVA farm...

by Dave Pigott

On 25 Jul 2012, at 19:29, Scott Bambrough wrote: > I have a modified JSON file here, but I basically can't send it, lava-tool tells me submit-job isn't a valid command, and I downloaded and installed from the latest bzr trunk. Am I missing something? Hi Scott, Not sure what's happening, so I'm copying in the rest of the validation list to see if someone can help. Thanks Dave

13 years, 1 month

more dispatcher leakage

by Andy Doan

Today I discovered that the dispatcher is still not deleting all its temp files. The current hole is demonstrated by our kernel CI loop. Basically, we aren't cleaning up temp files for ubuntu builds that send a hwpack plus RFS combo. To clarify, there are 3 types of deployments the dispatcher must support: 1) pre-built images 2) android images 3) hwpack + rfs Version 0.15.1 only cleans up files for 1 and 2. I spent some time today looking at the core problem which turned out to be an inconsistent approach to managing files the dispatcher creates. I created a common approach, moved code to use it, and then tested to make sure 1,2,and 3 work properly. I now have an MP: <https://code.launchpad.net/~doanac/lava-dispatcher/tempdir-madness/+merge/1…> That should fix all of this. I realize its the weekend, but I'd like to get this in to our 12.07 release which is targeted for Monday. Could someone take a sanity check? In the end, its better than what we have now -andy

13 years, 1 month

lava-dispatcher bug

by Andy Doan

Hey Guys, I found a major bug in our latest lava-dispatcher 0.15 release. This was causing pre-built image testing to not work and cache files in the lab to not get deleted which then led to service outages etc. Since the issue is huge, the fix is fairly minor, nobody is around, and we are headed into the weekend, I decided just to merge my change without peer review. Please double check my changes. I've tested them locally and on staging. I'm now deploying to production to hopefully stop the bleeding. Sorry for breaking all the rules here. -andy

13 years, 1 month

http://home.python-keyring.org/: [Errno -2] Name or service not known -- Some packages may not be found!

by Prakash Ranjan

Hi All, While installing LAVA-server with latest build out (revision 195 )I am getting the error message like *Download error on http://home.python-keyring.org/: [Errno -2] Name or service not known -- Some packages may not be found! *and after that the lava-server setting process is getting failed with message *While: Installing server. Getting distribution for 'docutils==0.9.1'. An internal error occurred due to a bug in either zc.buildout or in a recipe being used: * I tried to browse this page directly in browser but got error like server not found. Please help me on this issue... To see the complete log please got through the link http://paste.ubuntu.com/1099474/ Thank you Prakash Rnajan

13 years, 1 month

Errors when running lava-deployment-tool (the new "version" that uses buildout)

by Rafael Martins

Hi all, I'm trying to deploy a new lava setup here in my machine with the new lava-deployment-tool, and got an error, attached. doanac asked me in IRC to send the error to the mailing list, so it don't get lost. Thanks -- Rafael Martins <rafael.martins(a)collabora.com> Collabora Ltd.

13 years, 1 month

All those vexpress pre-built images

by Michael Hudson-Doyle

Hi, We seem to build three vexpress pre-built images daily: vexpress alip lt-vexpress alip vexpress ubuntu-desktop Is that intentional? Can we at least have the jobs testing them put their results in separate bundle streams? Cheers, mwh

13 years, 1 month

Inconsistent canonicalization of test case IDs in lava-test vs lava-android-test

by Alexandros Frantzis

Hi all, I noticed that lava-test and lava-android-test canonicalize test case IDs differently. For example, "[build] usevbo" becomes "buildusevbo" in lava-test and "build_usevbo" in lava-android-test. This is caused by a reversal in the order of character replacement actions: lava-test first removes badchars and then replaces spaces with underscores, whereas lava-android-test does it the other way around (which is the correct way). This issue affects tests that can run both on android and ubuntu (like glmark2), because it makes it hard to process information across test runs that ran on different platforms. I see the following options: 1. Change lava-test behavior to match that of lava-android-test (which works as expected). This is going to create backwards-compatibility issues for some tests, but I am not sure how much people care (I don't mind this happening for glmark2). 2. Add a mechanism that can be optionally used to make the lava-test parser work correctly. For example, by making the badchars property writable one could set badchars to [^ a-zA-Z0-9\._-] (note the additional space ' ' character at the beginning of the character set) to work around the problem. 3. Let the user handle this by writing a custom parser (e.g. one that would just override badchars property as noted above). If (1) is acceptable, I would vote for it, as it will solve the problem once and for all, without the need for any action from the user. Thoughts? Thanks, Alexandros

13 years, 1 month

[PATCH] Include 'ubuntu.image_type' in job metadata.

by Michael Hudson-Doyle

As we want to separate the vexpress ALIP and Ubuntu Desktop builds for QA purposes. --- lava-submit.py | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/lava-submit.py b/lava-submit.py index 2b65c3a..f9459b2 100755 --- a/lava-submit.py +++ b/lava-submit.py @@ -54,7 +54,8 @@ def get_test_actions(tests): }) return actions -def get_job(jobname, device_type, img_url, tests, image_name, image_number): +def get_job(jobname, device_type, img_url, tests, image_name, image_number, + image_type): stream = '/private/team/linaro/pre-built-%s/' % DEVICE_STREAM[device_type] job = collections.OrderedDict() @@ -69,7 +70,8 @@ def get_job(jobname, device_type, img_url, tests, image_name, image_number): }, 'metadata': { 'ubuntu.name': image_name, - 'ubuntu.build': image_number + 'ubuntu.build': image_number, + 'ubuntu.image_type': image_type, } }, { @@ -135,7 +137,7 @@ def main(): pass job = get_job(args.job_name, args.device_type, args.img_url, tests, - args.image_name, args.image_number) + args.image_name, args.image_number, args.image_type) user = os.environ.get('LAVA_USER') token = os.environ.get('LAVA_TOKEN') -- 1.7.9.5

13 years, 1 month

restoring staging db from backup

by Michael Hudson-Doyle

Hi all, I'm going to restore the staging db from the latest production snapshot today, so staging will be down for a while. Hope this isn't too disruptive! Cheers, mwh

13 years, 1 month

disk info in LAVA

by Andy Doan

We've tossed around this idea before, but I think its time to discuss something and put together a blueprint about pulling in SD card info into LAVA for each device. There are a few ways to do this, so I wanted to get some consensus on what people liked the most. My first thought was that ultimately the dispatcher is the component connected to the device, so it seems like its the place. However, that implies the scheduler ensuring the device is available, and probably taking the information from the dispatcher and pushing to our database. We'd also need to run this periodically. After thinking about that, I got to thinking we might be able to just piggy back off our health checks by simply adding a new dispatcher action (or maybe a lava-test) that from the master image pulls info like: /sys/block/mmcblk0/device/manfid /sys/block/mmcblk0/device/name /var/lib/lava/device.conf We could then roll this up into a test result and query from the DB? am i crazy?

13 years, 1 month

← Newer
1
...
63
64
65
66
67
68
69
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation