The Android team has a new app that can disable suspend on a device:
http://lists.linaro.org/pipermail/linaro-android/2012-April/000723.html
It can be enabled with commands like:
am start -W -a android.intent.action.MAIN -n \
com.android.disablesuspend/.DisableSuspendActivity
input keyevent 61 #key code for <TAB>
input keyevent 66 #key code for <Enter>
Looking at the changes we made to support this[1], I wonder if this new
method is safer. On the one hand this requires a change, and the change
requires us to start an application. This seems slower. On the other
hand, we are currently making sqlite3 calls and such that seem a bit
dangerous.
Thoughts?
1:
http://bazaar.launchpad.net/~linaro-validation/lava-dispatcher/trunk/revisi…
Hi, Andy
In the attached tjbench.tgz file, there are two files:
tjbench_job.json
tjbench_result.json
tjbench_job.json is the job file I used, I defined 7 tjbench actions in
that file.
and tjbench_result.json is the result of the job, I use lava-dashboard-tool
to get it from my local lava environment.
you can use put to upload it to your lava serve to see the result.
Thanks,
Yongqin Liu
On Thu, Mar 22, 2012 at 9:26 AM, Le.chi Thu <le.chi.thu(a)linaro.org> wrote:
> Hi Paul,
>
> I have worked with a UI driven test framework for Android earlier in
> STE and would like to use it for Linaro Android test (ok from STE
> side). We modified the code from open source TEMA project to work with
> ICS and would like to upload it the changes to the community.
>
> I created a blueprint for that
> https://blueprints.launchpad.net/lava-test/+spec/ui-drive-test-for-android
> to has time to do it.
>
Can you tell me how this differs from monkey runner? Sounds similar, and
Yongqin is already working on monkeyrunner support.
>
> Please priority.
>
> Here is the blueprints I would like to work with in next cycle and the
> highest first
>
> * health-check-job-vexpress (very small task)
> * Include STE kernel test suite in LAVA and CI
>
The above two are good ones, I know the STE kernel suite has some issues to
sort out wrt building though.
> * ui-drive-test-for-android
>
See above question.
> * manually-health-check
>
What is this about?
---------- Forwarded message ----------
From: Botao Sun <botao.sun(a)linaro.org>
Date: 5 April 2012 20:31
Subject: Re: How to integrate Connectivity Manager Test to LAVA?
To: YongQin Liu <yongqin.liu(a)linaro.org>
Cc: Paul Larson <paul.larson(a)linaro.org>, Abhishek Paliwal <
abhishek.paliwal(a)linaro.org>, linaro-android <linaro-android(a)linaro.org>
Hi Yongqin,
Yes, if the support for android command on android-build can be done, that
will be cool.
However, I'm afraid the Android team wants this test can be integrated as
soon as possible, and I won't work on this since I'm not in Android team
anymore. Basically I will provide some solutions or figure out a way to do
something, but won't do it by myself except in some special conditions.
Therefore, if LAVA team can do this, I will be very appreciated.
I agree with you about re-pack an apk is not a good idea. This is just a
temporary walk around way to do it, once we have an unique SSID for this
test, the source code of this test apk will be modified, then the repacking
work will be gone.
This test is new to us, and nobody has deep knowledge about the source code
inside. So there may be more changes in future according to our research.
Thank you for your help!
BR
Botao Sun
On Thu, Apr 5, 2012 at 10:18 PM, YongQin Liu <yongqin.liu(a)linaro.org> wrote:
> Hi, Botao
>
> On 5 April 2012 17:06, 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.
>>
>> I guess you can see
> http://bazaar.launchpad.net/~linaro-validation/lava-android-test/trunk/view… for
> a reference.
> and write a wrapper like that for lava-android-test
>
> If you are not urgent, I think you can wait util the support for android
> command on android-build,
> then you don't need to write the simple wrapper again.
> The discussion about it is now doing with the thread titled "Syntax for
> custom LAVA tests", this will be implemented in this cycle.
>
> 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.
>>
> I don't think repacking a apk is a good way.
>
> https://wiki.linaro.org/Platform/QA/TestCases/Android#android-net-
> ConnectivityManagerTest
> In the above wiki, I saw you can pass the ssid to the "am instrument", so
> I guess you can also pass it to lava from android-build page.
>
> Thanks,
> Yongqin Liu
>
>>
>> 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
>>>>
>>>
>>>
>>
>
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
