Hi all,
Inspired by, but mostly distinct from in the end, Spring's work on user
notifications, I've been working on adding "test run filters" to LAVA.
The idea is that you can define criteria for which test results you are
interested in. The next round of the work will be to allow subscribing
to filters (so you get an email when results matching the filter's
criteria are submitted), and maybe to allow sharing filters so other
people can view and subscribe to your filters.
The feature is live on staging now, please see:
http://staging.validation.linaro.org/dashboard/filters/
The code is at
https://code.launchpad.net/~mwhudson/lava-dashboard/test-run-filter
and has its crufty corners, but I think the design of the feature is
mostly OK.
Please let me know what you think!
Cheers,
mwh
Hi, I was looking into the daily pre-built tests and saw that panda was
still not tested since August 2nd. There's a problem with the prebuilt
image getting generated on jenkins that is unrelated, but I saw that on at
least 2 days, it did manage to build successfully, but no LAVA job was
started.
The server returned:
xmlrpclib.Fault: <Fault 400: "tag 'panda4430' does not exist">
I checked in the admin panel, and it looks like panda4430 and panda4460
tags were renamed to panda and panda-es. Was this intentional? Is it going
to stay this way? If we're going to use tags to identify which is which,
then we really need to make sure that they are stable names as we have
scripts depending on them already.
Thanks,
Paul Larson
Dave's on vacation, Michaels in NZ. Lets hold off on a meeting tomorrow.
We should probably re-think when/how we sync up now that the team has
changed so much.
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.
Just an FYI,
While doing some acceptance testing before deploying a new version of
the dispatcher to production I noticed a bug:
https://bugs.launchpad.net/lava-dispatcher/+bug/1032467
I'm not sure how our external users of LAVA have things configured, but
this could potentially cause you some breakage. I worked around our
issue in Linaro by adding:
tester_hostname = linaro
to the device-defaults.conf file.
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