Include: Nothing found for "^## meetings$"!

Include: Nothing found for "^## end-meetings$"!

This page is being re-factored. Most of the old content has been moved to LAVA


  • Actions from last meeting - Tech Lead chasing
  • Review activity reports - All team members
  • Engineer progress reports - All team members
  • Work Item progress and team issues discussion - Tech Lead and Project Manager questions to the team
  • Any Other Business (AOB)

Past Action items

  • Last weeks action items to discuss.

Action Items

  • Action items that came out of this weeks meeting.

Engineers Reports

Dave Pigott <davepigott>


  • Talking to leased line suppliers and gathering quotes
  • Looking at NAS solutions
  • Looking at USB hub solutions
  • Dealing with power supply and cable issues
  • Picked up Bug 771182 - Identified fix - awaiting re-org to check in


  • Face to face with leased line suppliers
  • Deploy more boards into validation lab
  • Look at data views and reporting


  • Half day Friday

Spring Zhang (springz)


  • Merged mp serial log attaching.
  • Summary user stories and work items for dispatcher from UDS discussion
  • Report a bug and fixed in abrek: [Bug 776268] [NEW] stream report error and no bundle file generate
  • Tracing an error "UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 941: ordinal not in range(128)", found in self.context.client.get_seriallog().

  • Submit a bug on MX53loco: [Bug 787722] [NEW] [imx53loco] system stop after DA9052 detection when boot up sometimes 'reboot'
  • A small mp about adding pkg dependency in abrek: merged


  • New blueprint and work items.

Issues & Absence

  • NA

Le Chi Thu <ChiThu>


  • Started to get the snowball hardware up. Still no received a working hardware pack from landing team.
  • Updated the Improvement of Abrek blueprint.
  • Started to merge outstanding approved merge proposal. Problem with the launchpad. The issue is fired to launchpad team.


  • Fix the reported bugs in Abrek


  • None

Zygmunt Krynicki <zyga>


  • Wrapped up previous cycle work items
  • Added some scenarios to dashboard improvements blueprint
  • Created lava-server with michael hudson (lp:lava-server)
  • Made lava-server capable of hosting "extensions" such as scheduler or the dashboard
  • Made the dashboard work with lava-server (in lp:lava-dashboard)


  • Work on token auth and lava-dashboard


  • It's too hot in Spain already ;-)

Paul Larson <plars>


  • Did some testing on the android lava branch
  • Made some fixes and merged basic support for android, more work to be done here still
  • Did some minor adjustments and merged Springs serial console log attachments branch to LAVA
  • Merged caching support, and several other fixes and catch-ups with what was needed to run in the validation farm
  • Redeployed lava to the validation farm using fully what is in trunk, created a separate branch for scripts to generate test jobs
  • Modified the Jenkins jobs so that they test all 4 LEBs on all of our boards, ran some tests and they seem to be going pretty well
  • Lots of work on Blueprints


  • Figure out what is still needed to get Android fully running in the lab
  • More blueprint and public plan review work


  • I will be out, Monday, May 30 for Memorial Day


  • None

Mirsad Vojnikovic <mirsad>


  • Working on adding some basic test cases to scheduler daemon implementation
  • Discussion about my scheduler blueprints proposal


  • Work on 11.11 scheduler blueprints proposal, finalize it and prepare work items for implementation


  • None

Michael Hudson-Doyle <mwhudson>


  • Collaborated with Zygmunt on splitting lava-server out of launch-control
  • Some work on authenticated API stuff (both server and client side)


  • Make a skeleton lava-scheduler as a lava-server extension and be able to make an authenticated call to it from lava-tool


  • Monday June 6th is a national holiday here.

Your Name <irc nick>


  • Short bullet points of work you've done that week which convey progress and highlights which can be used to report on how the team is progressing as a whole.


  • Your individual plans for the coming week(s).


  • Your individual plans for the coming week(s).

IRC logs

Meeting opened by plars at 01:02

  • <mwhudson> so who can kick zyga_ out of the channel? :)

    <plars> fabo: is here too I think

    <zyga_> hehe

  • mwhudson has set a reminder on his phone for the meeting now

    <plars> I can call his wife and tell her to drag him away from the computer

    <zyga> plars, she's right next to me

    <zyga> plars, we're all in the attic tonight

    <plars> [TOPIC] Actions from last meeting

Actions from last meeting

  • <zyga> guests at home ;-)

    <plars> hmm, it's not listed on the wiki page

    <plars> but the action from last week was for everyone to update the blueprints

    <plars> most people have done that

    <plars> I've done some editing on it as well

    <plars> if you have any updates, please get them in asap

    <zyga> plars, did you get a chance to look at dashboard improvements use cases?

    <plars> zyga: I did, I think they looked pretty good

    <plars> zyga: I will take a second look in a bit and at least approve the direction

    <zyga> ok

    <plars> zyga: the idea is, that on these higher level blueprints, or theme blueprints, or whatever you call them, we will have the user stories (sometimes epic stories)

    <zyga> ah

    <plars> those user stories can be in a sub-blueprint, which would contain actual work items

    <zyga> I knew 'use cases' was not the right term

    <zyga> right

    <mwhudson> i have been a bit slack at updating blueprints

    <zyga> just like stories + tasks on the backlog

    <plars> and we will add the detail to those as we go, not try to do it all at the beginning

    <springz> plars, do we keep the user stories in the blueprint

    <plars> so the idea, for now, is to try to sort the priority as best we can

    <plars> springz: yes!

    <plars> springz: and it's ok to add some bullets under them for clarification

    <springz> plars, seems we lost them in previous bp 11.05

    <springz> plars, ok

    <plars> when a new blueprint is created, please add the link to the whiteboard, and also make it a dependency

    <plars> springz: we weren't doing it like this in 11.05

    <plars> springz: we are trying to make some changes to the process, and it's all a bit experimental at the moment

    <plars> [TOPIC] Engineer progress reports

Engineer progress reports

  • <plars> yes I skipped activity reports

    <plars> I see no need for both

    <plars> I'd like to make this short since zyga refuses to sleep

    <plars> zyga: I think you have some good news to share

    <zyga> well there are some nice things showing up

    <zyga> mwhudson and me have split l-c into lava-server and lava-dashboard

    <zyga> (the latter is still somewhat broken if your run unit tests, works fine otherwise)

    <zyga> and just now I pushed token auth support for linaro-django-xmlrpc

    <plars> so the client pieces are going to go into lava-tool?

    <springz> zyga, is it easy to rename lp:xxxx branch name when bzr

    <zyga> lava-server is also (and this is actually interesting) a host for extensions, so you can hack your custom django appHH lava-server extensions like the scheduler and more easily

    <mwhudson> plars: yes

    <zyga> springz, lp:foo actually refers to more than just a branch, mwhudson knows if it's easy (probably not unless you have rights to do it)

    <zyga> plars, yes, I'll hack them early next cycle

    <mwhudson> springz: i can rename launchpad projects

    <mwhudson> springz: what's currently called lava will be renamed to lava-dispatcher shortly

    <plars> mwhudson: are you basically just excluding everything but the /lava/dispatcher tree for that piece?

    <springz> mwhudson, in lp:lava now there is scheduler code, will they also put into lava-scheduler?

    <plars> mwhudson: or is there more to it than that?

    <mwhudson> plars: no, that's basically it i think

    <mwhudson> springz: yeah, i'll copy that across

    <mwhudson> springz: there's not a lot there really

    <plars> mwhudson: if that's the case, then having a dev environment and deployment should still be very simple, good

  • zyga will hack on scheduler next cycle

    <mwhudson> plars: i'm not sure it's simple now tbh, but no harder than today :)

    <zyga> I'll probably implement the core logic unless someone wants to do it more eagerly than me ;-)

    <mwhudson> zyga: well, i'm trying to get to it but keep getting rabbitholed

    <plars> mwhudson: right, it's a pain to do the first time, more documentation should be written at a minimum

    <zyga> plars, the actual difference wrt server side apps is that you run lava-server in once place and hack in another

    <plars> but that goes for everything

    <zyga> plars, and that things like setup-dev-env are currently impossible to do in one shot, I'll make that possible next cycle

    <mwhudson> zyga: i have no problem with you actually implementing it so long as you do it a sensible way :)

    <plars> zyga: next cycle as in 11.11?

    <zyga> plars, 11.06

    <mwhudson> (i.e. we should talk before too much hacking happens)

    <plars> +1

    <zyga> mwhudson, absolutely

    <zyga> mwhudson, I'm mostly interested in the core logic for both scheduler and driver

    <zyga> mwhudson, the other 80% of the code will be much harder to write

    <plars> zyga: would be nice if you could write up an email about your plans with this, or better yet, a blueprint which corresponds to a user story

    <zyga> plars, I will design this and document the design before starting

    <plars> awesome, thanks

    <plars> mwhudson: any highlights other than what you just mentioned?

    <plars> mwhudson: also, if you could add your status to it will keep fabo from nagging you :)

    <plars> hmm

    <plars> perhaps we lost him

    <plars> springz: ?

    <mwhudson> ah soory\

    <plars> np

    <mwhudson> plars: no no real highlights, sort of slow progress on multiple fronts

    <springz> yes, I fixed the no bundle generated bug

    <mwhudson> mostly to do with being able to start on the scheduler from the command line end

    <plars> I saw, did I merge that yet?

    <springz> and look into the UnicodeEncodeError issue, actually, I'm tracing it these days

    <plars> springz: I think there was a comment or two I had on it, but I just glanced quickly. Will try to review that asap

    <springz> plars, yes, I proposed a mp

    <plars> springz: I think I checked in a workaround for that

    <mwhudson> plars: cool, i'll subscribe to updates to such pages, that should help me remember to do it :)

    <zyga> plars, springz: the unicode decode bug is actually more complex, you cannot treat serial data as unicode

    <zyga> it will never work properly

    <zyga> treat it as binary data and allow others to make heads and tails of it

    <springz> plars, I met it in one of my old attaching-seriallog branch, and in that situation, it is caused by pexpect.TIMEOUT

    <springz> and pexpect quit I think that time

    <plars> it's because StringIO can't handle unicode and 8-bit strings combined

    <plars> I ran into it today with the android stuff I was working on

    <zyga> mixing unicode and binary data is a mess, don't do it

    <plars> logcat seems to spew unprintable characters at the beginning

    <plars> zyga: right

    <plars> I cheated a bit, but using cStringIO makes it a non-issue

    <springz> plars, yes, cStringIO can help?

    <plars> and hopefully should be slightly faster

    <zyga> plars, I saw that, it might still break in the future

    <plars> zyga: if they add unicode support?

    <zyga> plars, I'd need to check but it seems that one coerces to unicode while the other does not

    <zyga> plars, if we don't need to have unicode let's use binary for now

    <springz> plars, I'll try it, but I'm confused that I didn't meet it when I do test in attaching-seriallog mp, I met it just after I put seriallog to the big bundle

    <zyga> I'd love to be py3k friendly but let's not obfuscate the issue with cstringio

    <plars> so for my part, I've been going through blueprints, and preparing for the public plan review, handled the serial attachment support merge with some minor fixes (thanks springz), did some catch-up fixes to lava-trunk and installed that on the validation server

    <plars> the scripts for generating the daily runs are in a junk branch of mine for now (they shouldn't be needed once we have a scheduler)

    <plars> so daily runs are in jenkins again

    <plars> and now are running on ALL LEB image types

    <plars> not just alip

    <plars> so we should probably rename that stream :)

    <plars> and fix the reports so they don't just look at that stream

    <zyga> plars, some reports would need updates as well, they implicitly look at that stream

    <plars> zyga: possible to rename in the admin console? or do I need to export/import?

    <plars> zyga: right

    <plars> that's what I meant

    <zyga> plars, it's trivial to rename via admin panel

    <plars> also, been looking at the android stuff

    <plars> the first bit is checked in, but for some reason 0xbench doesn't seem to generate results for me

    <plars> need to sort that out

    <plars> and it will need modifications to the master images

    <plars> we need an sdcard partition (vfat) for android

    <plars> dave will handle that obviously

    <zyga> are master images still manual or can I run a script and get master image for android?

    <plars> zyga: it's manual, but once you have one you can just back it up

    <zyga> ok

    <plars> zyga: depending on the size of your sd card, you may want to adjust the actual size of the partitions

    <zyga> yeah I get it, it's hard to automate

    <plars> zyga: but it's basically run lmc, shrink the rootfs, create a couple of new partitions, and install a few packages

    <plars> yeah, and we can do it once per board type, and just back up the image

    <plars> rather than automate it, I would almost rather just make a tgz of the dd img

    <plars> but it would still be specific to the size of the sd card like that

    <plars> so... if you have an easy way to automate it, it would be nice, but I don't consider it a high priority item

    <plars> it's not an especially hard process, just something that needs to be well documented

    <springz> plars, yes, it can't apply to a card which size is smaller

    <plars> springz: exactly

    <plars> ok, anything else for this section?

    <plars> ok

    <plars> [TOPIC] AOB


  • <plars> So we have 4 people here for this

    <zyga> I'd like to release some lava stuff on monday

    <plars> ok

    <plars> zyga: is it ready?

    <zyga> I'll spend tomorrow on fixing unit tests

    <zyga> plars, there is not much new stuff ;-)

    <zyga> just changes

    <plars> zyga: but this includes the split up server and dashboard

    <plars> right?

    <zyga> 0.5 will be the lava-rebranding release

    <zyga> yes

    <plars> zyga: that was my next question, this is going to include the name change right?

    <plars> yes

    <plars> good

    <zyga> yes

    <plars> awesome work

    <plars> the AOB I was going to bring up, is this meeting

    <zyga> plars, after that I'd like to have a brief brainstorm on the 0.6 focus

    <plars> we have 4 here, me, mwhudson, zyga (who shouldn't be here), and springz (who this might normally be too early for, and normally makes the other meeting time)

    <zyga> plars, I'd like to see scheduler integrated, xmlrpc unified and some initial documentation work but it's all open for discussion

    <plars> zyga: we will target some user stories to the 11.06 release

    <plars> milestone rather

    <plars> springz: which meeting time is more convenient for you?

    <springz> plars, if zyga is not here, it can be some time late

    <plars> because if this is normally just going to be me and mwhudson at this time, then I would propose we go back to the regular meeting time and have mwhudson catch up on notes and sync with me

    <springz> plars, but it's also convenient for me, I'll try to attend the meeting

    <plars> but if springz, or others would normally be here, then it makes sense to keep it

    <plars> ok, we'll try it a few more weeks and see how it goes

    <plars> just wanted to put the suggestion out there at least

    <springz> plars, I can attend Thur. night meeting, which we keep long

    <plars> so next week's meeting will be at 13:00 UTC instead

    <springz> plars, yep

    <plars> but we don't need to kill it now, let's see how it goes for a few more weeks and decide then

    <plars> ok, anything else?

    <mwhudson> nothing from me

    <plars> ok, thanks everyone

    <plars> #endmeeting

Meeting closed at 01:40

People Present

  • plars
  • mwhudson
  • zyga_
  • zyga
  • springz

Actions Recorded

internal/archive/Platform/LAVA/Meetings/2011-05-26 (last modified 2013-08-23 13:18:19)