linaro-validation August 2012

linaro-validation@lists.linaro.org

11 participants
16 discussions

by Michael Hudson-Doyle

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

12 years, 10 months

panda device tags

by Paul Larson

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

12 years, 10 months

validation meeting: cancel

by Andy Doan

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.

12 years, 11 months

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.

12 years, 11 months

potential configuration regression in latest dispatcher

by Andy Doan

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.

12 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

12 years, 11 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation August 2012