Forward to validation team
---------- Forwarded message ----------
From: Paul Larson <paul.larson(a)linaro.org>
Date: 5 April 2012 17:30
Subject: Re: How to integrate Connectivity Manager Test to LAVA?
To: Botao Sun <botao.sun(a)linaro.org>
Cc: YongQin Liu <yongqin.liu(a)linaro.org>, Abhishek Paliwal <
abhishek.paliwal(a)linaro.org>
SSIDs and things for the lab might need to be changed. We have the
internal documentation about ssids, wpa keys and such documented here
Yongqin:
https://docs.google.com/a/linaro.org/document/d/1XJsdKJGSdtfUC-BgfOsnTAF8GJ…
On Thu, Apr 5, 2012 at 4:06 AM, Botao Sun <botao.sun(a)linaro.org> wrote:
> Hi Yongqin,
>
> 1. Yes, it's already built in all Android images.
>
> 2. I think it should be submitted by android-build.
>
> There is a configuration file may need to be modified to
> keep corresponding with the SSID information in the test command, and you
> may need to re-pack this apk after that. Abhishek did it yesterday and you
> can get more details from his side.
>
> This is a cross platform apk, so once you finish the repacking, then you
> can re-install it on all our boards.
>
> FYI.
>
> Thank you!
>
>
> BR
> Botao Sun
>
>
> On Thu, Apr 5, 2012 at 2:07 PM, YongQin Liu <yongqin.liu(a)linaro.org>wrote:
>
>> Hi, Botao
>>
>> First I have some questions about this.
>>
>> 1. is the ConnectivityManagerTest.apk is built into the android image by
>> default?
>> 2. is the test job submitted by android-build or by another system of you
>> QA Service Team?
>>
>> Thanks
>> Yongqin Liu
>>
>> On 4 April 2012 19:57, Botao Sun <botao.sun(a)linaro.org> wrote:
>>
>>> Hi Yongqin,
>>>
>>> Recently I'm investigating the Connectivity Manager test, and I finally
>>> summarized a command list here:
>>>
>>>
>>> https://wiki.linaro.org/Platform/QA/TestCases/Android#android-net-Connectiv…
>>>
>>> However, I have no idea about how to integrate it to our LAVA system.
>>> The analysis of source code can be found in attachment of this email. Would
>>> you provide some information about it?
>>>
>>
>>> Abhishek runs this apk manually, and I will analyze the output once he
>>> sends to me.
>>>
>>> Thank you for your help!
>>>
>>>
>>> BR
>>> Botao Sun
>>>
>>
>>
>
Back to the public list...
On Sun, 1 Apr 2012 21:28:06 -0500, Paul Larson <paul.larson(a)linaro.org> wrote:
> On Thu, Mar 29, 2012 at 8:55 PM, Zygmunt Krynicki <
> zygmunt.krynicki(a)linaro.org> wrote:
>
> > W dniu 30.03.2012 03:40, Le.chi Thu pisze:
> >
> > > This worry me because the hold ideal with automation is you should
> > > able to recycle the device (when it stop responding).
> >
> > Yes but to do that you need reliable recovery boot method, typically
> > that is external to the device. We may be able to do this once PXE
> > booting and UEFI are commonplace.
> >
> Or, a piece of hardware that allows you to write/read directly to the sd
> from an external system. :) That's the long-term goal, but not so far off
> as you might think.
>
> Short term, I still think a tiny initramfs is the way to go.
So how would this work? Please excuse the train of consciousness style
below...
I guess the idea is that you have two uImage & uInitrd files on /boot,
and choose between them using uboot commands and so select booting into
test mode or master mode?
One extreme approach would be to have the master mode just dd an image
file completely over the mmc -- if you did this with the output of l-m-c
we'd have no way of recovering, but maybe we could run l-m-c on the
server, mush the boot partition of the image around a bit so that it
used a known good bootloader and booted to the master mode kernel &
initrd by default, then blat that over the mmc.
We could be more gentle in the master image, but that feels to me like
although we'd be able to use the expected partition layout, the
dispatcher/master image agent would have to know what it _was_ and
that's still pretty tedious -- although I guess you could just clone the
layout from the image file produced by l-m-c.... This feels like it
would be more reliable (e.g. losing power while the image is being
blatted over the mmc would presuambly require manual recovery).
I guess we'd have to be careful about resource consumption in our
initramfs -- presumably one has to fit rootfs and all RAM usage within
the RAM of the boards? I think Beagle xM's are our least capable boards
with half a gig of RAM, but all the others have a gig? That's
reasonably generous I guess, and we can customize our rootfs pretty
significantly, but I don't know if we'd want to write the master agent
in Python in this environment...
Cheers,
mwh
Hi all,
Thinking about various lab health and other issues has made me want to
see the current and historical state of a lab in a more sohpisticated
way.
I've messed around in inkscape a bit to show the sort of thing I mean --
can you guess what the attached image is meant to represent? I hope
it's fairly obvious, or there isn't much point in all this.
To be clear:
* each board gets a horizontal line
* time increases along the x-axis
* at a given moment, the line being narrow for a board indicates no job
is running
* a narrow green line means IDLE, a narrow grey line means OFFLINE
* a wider line means a job is running, or alternatively jobs are
represented by fatter blobs
* a red blob is a job that did not complete
* a green blob is a job that completed ok
Ideally, the view would support zooming and scrolling.
Mousing over a job should display a summary of the job, and clicking it
should go to the log page.
We could probably have a checkbox that would hide non-healthcheck jobs.
We might want a variant that has a line for each device type, and
somehow aggegrates the jobs running on different boards. Not sure how
this would work though.
I think we are storing all the information we need to create this view
(in the DeviceStateTransition table).
Do you guys think we should create this view? I would really like to
have it, but I don't have a clear intuition on how hard it would be. I
think it would make sense to mostly implement it in js, using some kind
of js library. I don't know of any library that would specifically help
(is there a name for this sort of visualization I can google for?) but
I'm sure it could be done with raphael (http://raphaeljs.com/) and maybe
d3 (http://mbostock.github.com/d3/) but I'm not really super up-to-date
on the latest whizzery in js visualization space.
Cheers,
mwh
Hi all,
One of the remaining pieces of the job health story is the
notification side: we should get an email whenever a health job fails.
The reason that I've been procrastinating about this for so long is
that it feels cheap to simply do "if job_failed and is_health_job:
send_email". It would be better to implement some more general
notification scheme and leverage that.
One existing blueprint in the area is this:
https://blueprints.launchpad.net/lava-dashboard/+spec/linaro-platforms-o-no…
which would get us a little of the way there: we could subscribe to
the failure of the job_complete test in the lava test suite, but that
would tell us about all failing jobs. We could beef up the
subscription model to limit to a bundle stream or something, but
*that* starts to feel a bit arbitrary (other options would be to
filter on test run tags or other bits of metadata).
I guess we should take this problem to the other WGs and find out what
notifications they would like to receive (if we can convince them to
care at all until we can test the bootloader :(), and in the mean time
do the cheap thing?
Cheers,
mwh
Hi, random, _crazy_ idea.
I've found two [1] [2] interesting artifacts from WebOS. We could
consider using them as adb replacements for ubuntu. This could allow
us to control master/test images with minimal footprint and without
installing python (to do just that, we may still need python for other
workloads).
It seems to be able to connect over plain USB as well as over TCP/IP.
[1] https://github.com/openwebos/novacomd
[2] https://github.com/openwebos/novacom
Best regards
ZK
--
Zygmunt Krynicki
Linaro Validation Team
We talked about this in our meeting last week. We should probably set
up a lava-job-submitters team in Launchpad, but until we do I gave the
permission to the group in lp.
Cheers,
mwh
Hi,
I prepared a merge request to update lava-test LTP test to the latest
released version 20120401 [1]. However, the new LTP test suite hanged
on creat08 and waitid02 tests when running on PandaBoard. Same tests
don't hang and even pass successfully on Snowball. How do we proceed
in this case?
off-topic question, why don't we provide an up-to-date LTP package
from Overlay PPA instead of building LTP on device during the test?
Cheers,
Fathi
[1] https://code.launchpad.net/~fboudra/lava-test/update-ltp-test-20120104
