Platform Validation Team Meeting

People Present


Action Items from last Meeting

plars to merge new dispatcher branch paulm_ to email his outstanding questions to plars and JamieBennett before the next phone call || || paulm_ || ||

Action Items this Meeting

  • zyga to talk to lool about ppa layout recommendations

Engineer Reports

Zygmunt Krynicki (zyga)


  • Packaged launch-control 0.3rc1. The fresh packages should be available from ppa:zkrynicki/lava in a few hours (two packages still need to build). Those are for lucid only. Once I test them I'll copy the binaries to maverick so that any non-edge system can just sudo apt-get install launch-control
  • Pushed USB power controller source code to The license is BSD, this is Lucian's original code. If anyone is interested they can have a look. This requires a USB Serial library available from sourceforge to build. It can be built using current codesourcery arm-none-eabi toolchain. Design blueprints will be made by Lucian in a few days. The tree includes all that is needed to build and flash the board. Lucian has a few more boards so I may be able to convince him to simplify the design (this is an adaptation of a board he just had available) and build a few more for the team. It would perhaps allow everyone to have same hardware and abstract the difference from the full-blown test farm to different connmuxd command used to reboot the boards

  • Added full support for 1.1 format to linaro-dashboard-bundle and launch-control. New features include binary attachment support (including mime type) and well-known source references. Source references allow to designate precise source code branch and revision for any number of projects and attach this to test results as context. It is currently being used by the GCC working group benchmark parser. This allows to show performance over a range of gcc revisions.


  • Finish deployment on This will make it possible to push latest and greatest test results into a more modern dashboard and get better feedback on what kind of reports are needed to make sense of the data. This task is mostly about me figuring out how to run l-c with WSGI + apache
  • Work on reports for generic benchmarks (optional)
  • Work on reports for day-to-day differences in pass/fail test results (optional)
  • Work on LAVA, get it running in the validation farm (optional)


  • Nope

Spring Zhang (springz)

=== Highlights ===

  • Working on test image deployment generate_tarballs interface based on new lava base, get lots of comments and plan to enhance.
  • Working on lp:lava branch remove-hardcode, which moves hard code to a python module, send merge request.

=== Issues ===

  • NA

=== Plans ===

  • Work on other parts of dispatcher.
  • Try to finalize dispatcher work items.
  • Contribute to dispatcher spec.

Mirsad Vojnikovic


* Finished and proposed merging lp:~mirsad-vojnikovic/lava/scheduler-example into lp:lava, which contains a skeleton for Validation Scheduler and gives a simple function for submitting test jobs to the dispatcher via message queue * Small addition to Validation Scheduler spec regarding LAVA database and API * Started working on work item for creation of database tables (models in django)


* Fix merge proposal according to the comments received * Look more into dispatcher parts, to see if there is something missing when it comes to communication with scheduler * Look at abrek, understand how it works and try to run something on a board


* I had to visit my dentist on Tuesday, so I couldn't work for 3 hours, which I will take as flex time during this week

Minutes IRC (Transcript)

  • <plars> [TOPIC] Actions from previous meeting

Actions from previous meeting

  • <plars> merge new dispatcher branch (plars)

    <plars> done

    <plars> which was the decision last week, and we are now working and making progress against that

    <springz> yes, thanks, a base version

    <plars> email his outstanding questions to plars and JamieBennett before the next phone call (paulm_)

  • lool sends healing waves towards plars' flu

    <plars> don't see paulm_, maybe robtaylor knows more on this... I know I got some followup emails from paulm_ which I responded to

    <JamieBennett> right

    <plars> so I'm assuming that's all

  • JamieBennett nods

    <plars> wow, I feel better already, thanks lool!

    <plars> [TOPIC] Work item progress (

Work item progress (

  • <plars> zyga crossed several items off of his list this week I know

    <zyga> plars, yes, I think I should be adding more items as the stuff I'm doing is not documented anywhere as work items, that's how I plan to proceed

    <plars> there has started to be some progress on the dispatcher now, slow at first but I'm encouraged because it seems to be unblocked

    <zyga> plars, as jamie said last time, no work items, no progress

    <plars> so just a reminder to take a look at your items and seeing if there's anything you can cross off

    <springz> zyga, which blueprint you are adding to

    <zyga> springz, to the ones related to benchmarks and test reporting

    <plars> yes, and that includes looking at your items and seeing if anything needs to be altered

    <plars> sometimes new work items are identified, sometimes old ones change to new ones, etc

    <springz> when can we finalize all of them

    <springz> for work items

    <plars> springz: I thought they basically were, but we can review them again if you like

    <springz> plars, ok

    <plars> springz: but that doesn't mean you have to work against a work item that you don't think still makes sense, or that you can't add anything

    <plars> [TOPIC] Brief Progress

Brief Progress

  • <plars> zyga: would you like to go first this week?

    <zyga> plars, sure

    <zyga> plars, so I'm a packaging person this week, I did a few bugfixes to the source code to make releases possible but most of my effort was spent on packaging everything needed to run launch-control inside ppa:zkrynicki/lava

    <zyga> sorry

    <zyga> overall it's rather easy (mostly python libraries and programs) but I'm struggling with the final piece, that is the web application

    <zyga> I read a ton of debian documents and consulted a few existing apps that seem to use django and am making good progress

    <zyga> I started looking at redmine (for dbconfig-common) pootle (for django bits) and now at mumble-django (for wsgi bits and file placement)

    <plars> I just noticed you were doing this in lava

    <plars> why there instead of in launch-control?

    <plars> zyga: ^

    <zyga> I started lp:~zkrynicki/+junk/django-hello which has a dumb django application, I'll follow up with packaging that makes it work, it already kind of works on my system but I still did not get the dbcommon stuff sorted out

    <zyga> plars, it's just part of lava I guess, I'd love to have full lava stack there

    <zyga> plars, get this ppa, deploy lava, run tests on your board

    <plars> hmm

    <plars> it's part of how we're using it, but it was really always a separate project right?

    <lool> we could call it part of the LAVA suite, but I think it's a good idea to have small independent pieces

    <plars> lool: how do you see that fitting in your proposal for how we change the way we do ppa's a while back?

    <zyga> I did not look at projects really, it's the linaro validation thing as far as I'm concerned

    <plars> that's what I was thinking

    <zyga> lool, what small independent pieces you mean? many ppas?

    <lool> plars: We have to weight how many people are going to use this; if it's a very small amount, maybe just publish in a ~linaro-validation owned PPA, otherwise, consider Ubuntu and optionally Debian

    <lool> zyga: I mean the software pieces we're discussing

    <zyga> lool, then I don't understand your comment

    <lool> keeping lp:launch-control and lp:lava loosely connected, with a simple contract

    <zyga> lool, that ppa has a few packages, we already have too much granularity IMHO

    <zyga> lool, that's how we currently do, there are about a dozen connected projects

    <lool> Maybe I didn't understand the "< plars> I just noticed you were doing this in lava" comment

    <zyga> lool, the ppa I built is just a container for the binaries, if it's about the name of that ppa I could not care less, we could call it "ppa"

    <zyga> lool, ah

    <lool> It's not too important if we have one PPA for lp:launch-control and one for lp:lava versus a single PPA for ~linaro-infrastructure projects

    <zyga> right

    <lool> It starts getting problematic when you have many changes in existing packages or intrusive one, or if you need many PPAs for e.g. daily testing, betas, final releases etc.

    <zyga> lool, this shows roughly how many projects are related to this, 90% of that is linaro stuff

    <plars> I just thought the name was a bit confusing

    <zyga> plars, ok

    <lool> For instance, I took the easy approach of putting conmux in ~linaro-maintainers/tools instead of talking to you folks

    <zyga> plars, unless we can rename the ppa I'd like to keep that as-is, we have more things to do :-)

    <lool> I didn't really push my PPA layout idea forward because it would require me to talk to each tech lead separately and review uses of PPAs in his team, and I just didn't have that time so far

    <zyga> lool, I have just one comment on ppa layout

    <lool> I hoped convincing people to use this layout was all I would have to do, but it is not easy to change habbits :-)

    <zyga> lool, we should have a ppa for common stuff like "this is the linaro backports that we use"

    <lool> *habits

    <zyga> lool, and then we could consider doing ppas with ppa-dependencies

    <lool> zyga: I'm not sure

    <zyga> lool, as far as my ppa is concerned I _did_ have to backport packages,

    <lool> zyga: but it's a larger topic, we can cover it outside of the meeting

    <zyga> ok

    <zyga> fine with me

    <zyga> lool, one more thing

    <plars> [ACTION] zyga to talk to lool about ppa layout recommendations

zyga to talk to lool about ppa layout recommendations

  • <plars> no, no more things

    <plars> :)

    <plars> j/k

    <zyga> lool, once I'm done perhaps we could publish django-hello for package maintainers review and decide how to package django apps in debian on a wider forum

    <zyga> so that's all from me

    <plars> thanks zyga

    <plars> springz: your turn

    <springz> plars, ok

    <springz> 1. send lp:~qzhang/lava/gen-test-tarball merge proposal, and receive lots of good comments to enhance, it needs fix

    <springz> 2. send lp:~qzhang/lava/remove-hardcode, get comments and fix, resend mp today, does it meet your comments now? It's only a module for import currently

    <springz> 3. do a quick test on 11.05alhpa3, met mmcblk0 error and only get a initram login

    <springz> on mx51evk

    <plars> springz: will take a look this morning but I haven't had a chance to yet

    <plars> for #2

    <springz> plars, ok, for RC test, do we need to try ubuntu rootfs?

    <plars> I won't bother adding an action for that, since reviewing branches is just a normal part of what we should all be doing

    <lool> springz: lp:~qzhang/lava/remove-hardcode > I had a quick, and it seemed fine; I would like try to move to unittests instead of main, and perhaps rename some constants, but we can do that at merge time

    <lool> +look

    <springz> lool, where can I add to unit test?

    <springz> lool, is there a fixed place

    <lool> springz: In linaro-image-tools, we have a tests/ subdir under the files which are being tested

    <lool> But it's just a convention I guess

    <lool> springz: I can try to convert your test as an example

    <springz> lool, ok, I'll have a look at l-m-c

    <plars> springz: we are mostly concerned with looking at Linaro images for Linaro work, but if you have supported hardware and want to try the Ubuntu images in free time, that's fine... or do I misunderstand?

    <springz> plars, right, got it

    <plars> ok, anything else from you springz?

    <springz> plars, I always feel there is some piece lost for lava

    <zyga> lost?

    <plars> springz: how do you mean?

    <springz> plars, block it can run easily

    <springz> I mean there should be a easy way to deploy it and run

    <springz> does it PPA do

    <plars> well it's a branch in bzr, so once we have all the actions filled in, we should at least be able to pull it and run the dispatcher part

    <zyga> springz, we can package it, I would love to do that in my ppa once it matures a bit so that we have something to deploy, I know plars wanted to wait until we have some significant advantage to doing that though

    <plars> which is pretty simple

    <plars> right

    <zyga> springz, but we can package dependencies to make the job easier

    <plars> right now, there's really no advantage to packaging it

    <springz> plars, zyga ok

    <springz> that's all for me

    <plars> springz: is this creating a problem for you, or blocking you in any way?

    <springz> plars, I just want to create an environment easily

    <springz> for lava

    <plars> springz: where are you finding it to be difficult?

    <plars> I didn't think lava had so many dependencies already that packaging should be an issue

    <plars> isn't it more of an infrastructure thing that complicates it?

    <springz> er~, like some installation script, but as we talked, it came later

    <plars> springz: ok, I'm not fully understanding how this is an issue right now, but if it's causing problems for you please send and email or talk to me later and we'll get it sorted out

    <plars> I want to make sure we don't have anything blocking anyone

    <plars> thanks springz!

    <springz> plars, ok for me, currently we don't need to install it, just pull

    <plars> right

    <plars> exactly

    <plars> we should try to keep it that way unless there is a reason to break it

    <plars> as it makes development much simpler

    <plars> springz: I should have checked first, sorry, did you have anything else?

    <zyga> plars, IMHO this way of doing things will backfire

    <zyga> plars, 'it should work from a checkout'

    <zyga> plars, it breaks quickly down this path

    <springz> plars, what do you mean, status?

    <plars> springz: right

    <zyga> plars, we should plan for next step, not avoid it forever

    <springz> that's all for me

    <plars> zyga: well, it works well for a lot of other projects, and as I mentioned, if we have a reason to deviate from that then we should. But we shouldn't break it just to break it

    <plars> moving on

    <lool> springz: Creating an environment easily: that's also my goal

    <plars> mirsad: can you go now please?

    <lool> Which is why I added this QUICKSTART doc and packaged conmux

    <mirsad> plars, yes (hi all!)

    <springz> lool, yep, we will met in the future I think

    <mirsad> plars, I have tried to update the sched. spec as per your comments, and it is done

    <mirsad> plars, then I went on to create database according to the spec

    <mirsad> plars, and that is also ok

    <mirsad> plars, then I'm continuing with some basic web UI

    <plars> mirsad: is that checked in to bzr somewhere?

    <mirsad> plars, however, I need to know what to do with message queue

    <mirsad> plars, no, I would like to know where to continue, if my proposed merge is ok?

    <plars> I thought we decided to look at doing the message queue later if it became apparent we really needed it

    <mirsad> regarding message queue

    <mirsad> plars, was that a decision, I did not get it

    <springz> mirsad, I would like to think of it, a question discussed before

    <plars> we discussed it several times in email I thought

    <plars> if we do it, then it means we have to also implement a daemon to pick up the messages and start a dispatcher for them

    <plars> which would be sitting on the same machine

    <mirsad> plars, yes, but where is the decision? I put a question about that, but no answer

    <plars> this seems like an unnecessary piece to me

    <mirsad> plars, I have no problem with that

    <springz> mirsad, there are two decisions I think, one is one queue, another is one queue one board

    <plars> unless someone has a big reason why they think we need this right now, consider it decided

    <springz> mirsad, for if we use it

    <mirsad> plars, then the proposed merge can be dismissed, I will rework on it

    <plars> mirsad: the last email I got from you make it sound like you felt very blocked on more than just the message queue stuff

    <plars> mirsad: how can we help with this?

    <mirsad> plars, let me read that mail

    <zyga> plars, how do you plan to run multiple jobs in parallel in the simplified architecture?

    <mirsad> plars, yes, database parts - is this db setup ok (tables), also fields

    <plars> zyga: can't you start a process to run the dispatcher for each job?

    <plars> zyga: that's what the daemon would need to do anyway right?

    <plars> mirsad: I'll take a look today

    <plars> springz: you should take a look too, as it mostly affects the dispatcher

    <springz> plars, ok

    <mirsad> plars, that would be good, and it is not so complicated at all (to start with)

    <plars> thanks mirsad, anything else?

    <zyga> plars, you can, I was just interested in the method you wanted to use, I'm not sure which daemon you were referring to but in the design I planned to use it would be just a single daemon that can manage arbitrary number of jobs (but that is abstracted away) via multiprocessing used by celery

    <mirsad> plars, one small thing more - I'm ready for Budapest

    <plars> mirsad: good! if you have your flights already please put them on the wiki page if you haven't already

    <mirsad> plars, too bad there was no WI for that, since it took almost a day

    <JamieBennett> :)

    <plars> heh

    <plars> yeah, travel can be like that sometimes

    <plars> zyga: something would have to be on the receiving end of all this to launch them all

    <springz> zyga, loop the received jobs and probe dispatcher for every job if no conflict boards

    <plars> ok, almost out of time

    <plars> [TOPIC] Any other business

Any other business

  • <JamieBennett> o/

    <JamieBennett> So I have a couple of points

    <plars> JamieBennett: yes?

    <JamieBennett> Please test the images today, alpha-3 will be released later

    <plars> indeed

    <JamieBennett> if you only test ubuntu-desktop thats fine

    <lool> JamieBennett: when is A3 release?

    <JamieBennett> lool: later today

    <plars> [LINK]

  • <JamieBennett> other point

    <JamieBennett> As a team we need to start producing activity reports

    <JamieBennett> to be in line with the rest of the platform teams

    <JamieBennett> and to help the PM (me) produce reports to management e.t.c

    <JamieBennett> (and let Paul do other things instead of that)

    <zyga> JamieBennett, what would you expect from our side?

    <JamieBennett> Each week before the meeting you should edit the meeting wiki page with your activity report

  • plars thinks that's JamieBennett's nice way of saying I stink as a fill-in pm :)

    <JamieBennett> tells you what you need to do

    <JamieBennett> plars: hehe, let you go do other things

    <JamieBennett> so, for next week if you add your activity reports before the meeting we can discuss any issues

    <JamieBennett> and I'll produce the report

    <plars> that's a good point

    <JamieBennett> plars: if you'd like I can take over chairing the meetings from next week too

    <plars> that way you can add things directly rather than just emailing me

    <plars> I'll still send an email reminder to do this

    <JamieBennett> plars: indeed, no more emails, just edit the wiki directly

    <plars> JamieBennett: it's really that bad huh?

    <zyga> JamieBennett, that link shows something that looks awfully like our weekly reports

    <zyga> JamieBennett, is there any change apart from recording this on the wiki

    <plars> JamieBennett: really, I don't care, if you prefer to do the meetings that's fine, but I'm ok with doing them too

    <JamieBennett> plars: OK, I'll be your back-up

    <JamieBennett> zyga: I've not seen your activity reports before but if they follow that syntax then awesome

    <zyga> JamieBennett, that's exactly the syntax we use

    <plars> I'll include instructions in next weeks reminder to put your status in

    <JamieBennett> great, just add them to the wiki and we are all set :)

    <plars> any other quick items?

    <JamieBennett> is an example of what it should look like

    <lool> I just wanted to say I packaged conmux in the linaro-maintianers/tools PPA

    <plars> lool: yay!

    <lool> the next thing I will work on is actually running lp:lava here, locally, and updating the QUICKSTART instructions

    <plars> thanks lool for all the help you've given recently

    <lool> then I intend to work towards deploying it in Cambridge

    <lool> (no idea what that entails)

    <lool> I'll try to continue doing code reviews, adding tests etc. to the code

    <lool> this is best effort, so feel free to takes tasks from me!! :-)

    <lool> seems we're out of time

    <plars> yep

    <plars> #endmeeting

internal/archive/Platform/LAVA/Meetings/2011-03-03 (last modified 2013-08-23 13:19:02)