Hey all,
Lately I've been studying the LAVA QA Tracker by looking at its code,
setting it up on a LAVA dashboard instance in a VM and trying to use it,
and asking some questions on IRC.
I recall asking at the beginning of the month if there were plans on the
Linaro side to allocate developers to finish the QA Tracker in a
specific timeframe, and was told that some development for this
[monthly] cycle should start "next week".
However, except my own bazaar branch (crappy; it does not really
solve/fix anything so far), I haven't heard of recent development
activity. Or did anything happen that I missed?
Also, some people I spoke with were not aware at all of those plans for
this cycle. So I'd just like to check out a few things:
- Do you have a target deadline to meet for this?
- Who are the people who will specifically be working on this?
Thanks :)
Hi, All
Now lava can support to specify android commands in the job file directly,
and this makes it necessary for us to discuss the interface on
android-build page that used to generate the expected lava job files.
I have written some description about this interface on the wiki:
https://wiki.linaro.org/Platform/Android/AndroidBuild-LavaIntegration
The BP is
https://blueprints.launchpad.net/lava-android-test/+spec/modify-android-bui…,
and pfalcon has already given some comments there.
You can see that for your reference.
And here I want to get more feedback from you about it to make it more
convenient for us to use.
Please give me your comments.
BRs,
Yongqin Liu
On Fri, Mar 23, 2012 at 10:48 PM, Andy Doan <andy.doan(a)linaro.org> wrote:
> On 3/23/12 8:02 PM, Amit Kucheria wrote:
>
>> Wow, this looks quite involved. Learning Django (and python as a
>> pre-req) is steep. I guess I was hoping for something quick and dirty
>> akin to gnuplot munging some data into a graph.
>>
>> Hongbo, how is your python?:)
>>
>> I guess we'll have to see if we can steal some existing code and beat
>> it enough to get something useful for us.
>>
>
> You can look at the dashboard's javascript "report" interface:
>
>
> http://bazaar.launchpad.net/~**linaro-validation/lava-**
> dashboard/trunk/files/head:/**examples/reports/<http://bazaar.launchpad.net/%7Elinaro-validation/lava-dashboard/trunk/files…>
>
This really isn't recommended. It's not what I would call easy - as it
requires rooting around in the tables created by the model with sql. The
sql you write will have to be written for postgres at least, but if you
test using sqlite locally, you may have to adapt it to both.
I just don't know if that's enough for your needs or not.
>
> I was no Django or Python expert and found copying the existing code easy
> enough to get started.
>
Agree, the python/django aren't that bad really. The trickier bits (for me
at least) always seem to be the css and javascript, which are going to be
largely unavoidable if you want to do anything visual.
Thanks,
Paul Larson
Hi, Zygmunt,
Do we have some document to log frequently asked questions? Especially in
no doc projects like lava-tool, lava-scheduler-tool
If we find some issues and resolve it, we may log them to somewhere.
--
Best wishes,
Spring Zhang
I've added a new job called 'porter' which reserves the first tcpanda
that comes free. This can be used to reproduce a bug or benchmark
result against an existing binary build.
For example, say you want to see if a fault exists on recent trunk:
* Go to http://ex.seabright.co.nz/helpers/buildlog/gcc-4.8
* See the last successful ARM build was gcc-4.8~svn185503
* Go to http://ex.seabright.co.nz/helpers/scheduler/spawn
* Spawn a job called 'porter' into the a9-builder queue
* Keep polling http://ex.seabright.co.nz/helpers/scheduler until a
board shows as 'porter/ready'
* Log into the board using ssh cbuild(a)board.v
* Change to /scratch/cbuild/slave/slaves
* rsync the binary across using rsync
control:~/cbuild/build/gcc-4.8~svn185503/gcc-*cortexa9*xz .
* Extract the binary and have at it
The board will drop back into the queue after 48 hours. You can
release it early by doing a 'killall sleep'. Please do any work under
/scratch/cbuild/slave/slaves as this is automatically deleted when the
next job starts.
Zhenqiang, could you add this to the jobs page please?
-- Michael
I think this is only affecting Zygmunt and I for the current incarnation
of sentry, but the bug I filed with sentry about not being able to turn
off email got fixed and released, so I upgraded and restarted it.
I'd quite like to disable the 404 notifications (do we actually care?),
but what do other people think?
Cheers,
mwh
Hi
Ti took the liberty of building a script that automates construction of
LAVA master images. The work is not finished but the bulk of the work
has been done (and greatly facilitated by Dave Pigott's partitioning
script).
The design is somewhat different to what we had before but the output is
compatible. The script can be summarized in three points:
1) Start with a good nano image (or build one)
2) Add stuff to rootfs, changing a few existing files (/etc/hostname,
/etc/hosts, fixing /etc/network/interfaces if buggy)
3) Boot the board and let the first-boot script do the rest
I've registered a blueprint that tracks the remaining work items [1]
Feel free to help but please change the work item to be assigned to you.
I will definitely need some help with origen as I don't have that
hardware at home. I will script the construction parts but I cannot run
any tests to make sure it works.
[1]:
https://blueprints.launchpad.net/lava-master-image-scripts/+spec/lava-maste…
Best regards
Zygmunt Krynicki
As per Zygmunt's request, adding linaro-validation for discussion.
Dave
Dave Pigott
Validation Engineer
T: +44 1223 45 00 24 | M +44 7940 45 93 44
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On 20 Mar 2012, at 14:33, Zygmunt Krynicki wrote:
> W dniu 20.03.2012 15:22, Dave Pigott pisze:
>> Hi,
>>
>> I think we need to seriously look at allowing a timeout parameter around
>> "deploy_linaro_image", because vexpress is going to need around 4 hours
>> to deploy a full desktop, and it seems crazy that we should hard code
>> that big a timeout into master.py for *all* platforms.
>
> Could we move that to linaro-validation please?
>>
>> I realise there is an issue as to which part the timeout is applied to
>> and how it's apportioned, but even if we just allowed to pass through
>> the whole timeout to each stage it would be better than what we have at
>> the moment.
>>
>> Thoughts?
>>
>> Dave Pigott
>> Validation Engineer
>> T: +44 1223 45 00 24 | M +44 7940 45 93 44
>> Linaro.org <http://www.linaro.org/>***│ *Open source software for ARM SoCs
>> Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro>|
>> Twitter <http://twitter.com/#!/linaroorg> | Blog
>> <http://www.linaro.org/linaro-blog/>
>>
>
>
> --
> Zygmunt Krynicki
> Linaro Validation Team
Hi
Experimenting with the dispatcher made me realize that forced reboots
(on timeouts, for example) are an excellent way to damage the master
image. At the very best we are forced to re-check the master image. At
the very worst we may damage the superblock and generally hose the master.
Do you think it is feasible to mount the master read-only and only do
r/w work on the test partitions?
--
Zygmunt Krynicki
Linaro Validation Team
