linaro-validation July 2012

linaro-validation@lists.linaro.org

22 participants
25 discussions

Re: [Linaro-validation] what's the open-embedded platform bringup story

by Marcin Juszkiewicz

W dniu 30.07.2012 16:10, Alexander Sack pisze: > Hi, > > big items we need to sort out: > > + linaro-media-create install support > + lava-test support > + lava support I had some thought on it (OpenEmbedded builds and LAVA) and due to that here are some questions. 1. Do tested image needs to have LAVA client code installed? If it does then I would have to add LAVA client components into OpenEmbedded because I can not use Ubuntu packages as they are not compatible with each other. 2. Does lava build require rootfs + hwpack or can boot with just rootfs? Rootfs will contain kernel in /boot/uImage and u-boot configuration in /boot/boot.scr (or other defined location). If hwpack is required then I will have to create one with OE and add support for them in l-m-c (as we can not use Ubuntu packages for things other than kernel/bootloader cause there is no warranty about binary compatibility). > I think if the fast model route is blocked we should take the pain to > work on real board. For now using real board is less pain then using fast model. I have real boards available at home so can test images on them.

13 years, 11 months

json schema help

by Andy Doan

I'm not really finding good sources for help with defining json schema rules, so I thought I'd ask here. I'd like to update our current boot-linaro-image action in the lava-dispatcher to take a new optional parameter called "boot_options", eg: { "command": "boot_linaro_image", "parameters": { "options": [ "coretile.cache_state_modelled=1" ] } } I tried to do this by updating parameters_schema in boot_control.py with: +_boot_schema = { + 'type': 'object', + 'properties': { + 'options': {'type': 'array', 'items': {'type': 'string'}, + 'optional': True}, + }, + 'additionalProperties': False, + } However, now "parameters" is always required which we would be horrible for backward compatibility. Anybody know how I should go about this? -andy

13 years, 12 months

Re: [Linaro-validation] Some thought about the implementation of black-box test

by YongQin Liu

+ @linaro-android + @linaro-validation On 27 July 2012 09:32, YongQin Liu <yongqin.liu(a)linaro.org> wrote: > > > On 13 July 2012 11:19, Michael Hudson-Doyle <michael.hudson(a)linaro.org>wrote: > >> YongQin Liu <yongqin.liu(a)linaro.org> writes: >> >> > Hi, All >> > >> > Here just some thought about the implementation of black-box test. >> > If you have any ideas, or something I missed, please give a comment. >> > Anything will be appreciated. >> >> Thanks for sending this. >> >> > ------------------------------------------------------------ >> > *Glue between lava and android* >> > In android there is a directory /data/blackbox_tesxt/, under it are >> TODO, >> > TESTING, DONE 3 direcories. >> > >> > - TODO: the flags for test that need to run will be put here >> > - TESTING: the flags for test that are running will be put here. >> > normally, there should be only one entry.In the future will be more >> > entries when we support test execution via thread >> >> Do we actually want to support running more than one test at once? It >> doesn't seem like a super good idea to me. >> > > Yeah, seems support only one test once is more realistic now. > If so, seems we just need one action that will do > install/run/wait/get_result > > >> > - DONE: the flags for test that have been completed will be put >> here >> > >> > About the entry format, will use JSON or just key/value pair. but need >> to >> > have the following two features >> > 1. one item to indicate the command to run >> > 2. other items used for pass information between android test tool and >> lava >> > job >> > >> > *Black-box test framework on Android* >> > On android, a test framework will check the entries in TODO, and run the >> > command indicated in the entry. >> > Before the test is start to run, the framework will put the entry to >> > TESTING, and after test finished will put the entry to DONE. >> > when run the test command, this framework will run the command and pass >> the >> > entry file as parameter. >> > >> > The black-box test framework in android mainly do: >> > 1. invoked after boot up and home screen is displayed. >> > also charge for prepare the test environment like unlock screen, >> > disable suspend >> > 2. charging for invoking test command and changing the status of the >> each >> > test >> > >> > *Framework on LAVA* >> > >> > Will have 2 actions >> > 1. install_black-box_test >> >> Will this action have a list of tests to install? >> > I'd like to install one test with one action. > as I described in another mail. > >> >> > 2. wait_black_test_finish >> > will loop to check until there is no entry in TODO and TESTING >> > also will check if the test framework is running, if it is not in ps >> > and there are still test to be run, will invoke it to run. >> > show the output of the running test >> >> Do we want to reboot between tests? >> > I think this can be done out the lava-dispatcher like the system-reboot on > android-build now. > > > Thanks, > Yongqin Liu >

14 years

Some thought about the implementation of black-box test

by YongQin Liu

Hi, All Here just some thought about the implementation of black-box test. If you have any ideas, or something I missed, please give a comment. Anything will be appreciated. ------------------------------------------------------------ *Glue between lava and android* In android there is a directory /data/blackbox_tesxt/, under it are TODO, TESTING, DONE 3 direcories. - TODO: the flags for test that need to run will be put here - TESTING: the flags for test that are running will be put here. normally, there should be only one entry.In the future will be more entries when we support test execution via thread - DONE: the flags for test that have been completed will be put here About the entry format, will use JSON or just key/value pair. but need to have the following two features 1. one item to indicate the command to run 2. other items used for pass information between android test tool and lava job *Black-box test framework on Android* On android, a test framework will check the entries in TODO, and run the command indicated in the entry. Before the test is start to run, the framework will put the entry to TESTING, and after test finished will put the entry to DONE. when run the test command, this framework will run the command and pass the entry file as parameter. The black-box test framework in android mainly do: 1. invoked after boot up and home screen is displayed. also charge for prepare the test environment like unlock screen, disable suspend 2. charging for invoking test command and changing the status of the each test *Framework on LAVA* Will have 2 actions 1. install_black-box_test 2. wait_black_test_finish will loop to check until there is no entry in TODO and TESTING also will check if the test framework is running, if it is not in ps and there are still test to be run, will invoke it to run. show the output of the running test 3. collect_test_result parse and upload to lava ------------------------------------------------------------ *Related BPs* 1. lava side: https://blueprints.launchpad.net/lava-dispatcher/+spec/black-box-test-actio… 2. android-side: https://blueprints.launchpad.net/linaro-android/+spec/support-blackbox-test Thanks, Yongqin Liu

14 years

Moving cbuild into the validation lab

by Michael Hope

I'd like to move the cbuild infrastructure out of my home office and domains and into the validation lab. That makes things one step cleaner than the current setup and one step closer to hooking things into LAVA. There's more terse notes at: https://wiki.linaro.org/MichaelHope/Sandbox/CBuildMove but here's how I'd deploy it: * Create cbuild.linaro.org to replace ex.seabright.co.nz * Add a real or virtual medium capacity machine to run the web server, scheduler, snapshotter, storage, and other administrative stuff * Add 500 GB+ of backup storage * Add a reverse proxy to expose the server to the internet * Delete orion that currently runs ex.seabright.co.nz * Delete the EC2 micro instance that runs apus.seabright.co.nz * Redirect and delete builds.linaro.org tcserver01 stays as a build and benchmark machine. I'm not happy with control being the web server, bounce host, and a build machine. It's too taxing and unreliable. I'd like an unloaded minimal host there instead. Thoughts? Who can drive this? -- Michael

14 years

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

14 years

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

14 years

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

14 years

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

14 years

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.

14 years

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation July 2012