Validation Team Meeting
- Actions from last meeting - plars chasing
- Engineer progress reports - All team members
Work Item progress and team issues discussion - Paul and JamieBennett questions to the team
- Any other business (AOB)
Past Action items
- plars/lool to discuss uboot mmc possible problems
JamieBennett to see if freescale can get us a reworked imx53
plars or springz to forward imx53 rework info to JamieBennett
Zygmunt Krynicki <zyga>
- Work on lp:~zkrynicki/abrek/szarik to support:
- External tests defined in .json files (no need to write python anymore)
- Ability to registered new tests at runtime with "abrek register-test URL"
- Native JSON tests that allow you to create a JSON file with test results that can use all the features of the dashboard (work in progress)
- Ability to define custom test providers
- Re-factored test providers to have 3 default providers:
- - built in tests (in abrek tree) - tests defined by installed 3rd party python packages (out of tree, uses python pkg_resources entry points to locate tests) - tests defined in JSON and registered with abrek register-test
- Configuration file to store registered test (it's JSON yes)
- Had a follow up phone call with Paul Larson and Torez Smith about power management tests
- Work on launch-control and friends
- Fixed a ton of bugs in that crept only show up with more strict postgreSQL backend
- Released all the way up to launch-control 0.3c6
- Pinged Canonical IS to deploy everything via RT ticket (writing email now)
- Drive from Warsaw to Barcelona (via Słubice, Luxembourg and Lyon)
- Have a nice weekend in Luxembourg
- Stop at a hotel in Barcelona
- See the houses we selected earlier
- Sign a contract
- Get a Spanish SIM with good data plan
Start a new life in Spain
- Bundle data format does not specify maximum lengths permitted. This creates an impression that anything is allowed while the implementation is not as forgiving. This is a design issue on my part that went unnoticed for months because SQLite just ignores maximum length for text fields.
- Off-line for most of next week
Dave Pigott <davepigott>
- Started on Monday morning
- Got connected and set up - an ongoing process!
- Intro to hardware and build from DaveM
- Read some of the intro material
- Became the in-house net-admin somehow
- Get inbound port forwarding working again
- More background research and reading
- Get more boards set up in the cabinet
- Moving house over the next week, so will be out for some portion of this Friday and a couple of hours during next week
Spring Zhang (springz)
- Merged lp:~qzhang/lava/test-abrek.
- Merged a quick patch for prompt matching string in lp:~qzhang/lava/lava-remove-hardcode.
- Start working on submit_results with Launch Control, set up a Launch Control server, and use lc-tool to interact with l-c server.
- Working on ongoing branches/work items: submit_results.
- Enhance dispatcher blueprint and spec.
Mirsad Vojnikovic <mirsad>
- Merge proposal for initial scheduler delivery covering database models WI, delivered fixes for review comments
- Started work on scheduler daemon
- Continue working with scheduler daemon
- Install Apache and PostgreSQL locally to run scheduler in a production-like environment
- Not able to use bzr from work due to STE proxy, it's starting to be really annoying. I have sent a request internally for whitelisting launchpad.net SSH, but no progress, will follow up this
Paul Larson <plars>
- Installed conmux on the lab server from the new package, migrated configurations
- code reviews
- Helped Dave Pigott with some lab issues
- Did some testing on launch-control, filed some bugs
- Merged my fixes to finish out the deploy action in dispatcher
- Did some minor fixes to abrek to make it work with the latest launch control revisions
- Did a test of all the actions we have supported in lava dispatcher, by setting it up and submitting a job to deploy an image, install abrek and a testsuite, and run the testsuite with a bundle generated. A few minor fixes were needed along the way, which I will check in today, but it worked!
- Continue to look for gaps I can help fill in, anywhere in lava
- Help get our new team members started off
- Work on refining some plans for dashboard priorities.
- Router instability in the Cambridge office continues to be a source of trouble. It is infrequent, but disruptive when it occurs. We have a plan in place to replace this router very soon.
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).
Started logging meeting in #linaro-meeting [14:02:52] <davepigott> My fault. I was on private [14:02:52] <plars> [LINK] https://wiki.linaro.org/Platform/Validation/Meetings/2011-03-24 [14:03:12] <plars> [TOPIC] Actions from last meeting [14:03:20] <plars> plars/lool to discuss uboot mmc possible problems [14:03:35] <plars> we never really got around to this, but my understanding is that it's unlikely to have problems [14:04:17] <plars> unless you have something to add lool? [14:04:44] <plars> we can talk about it later if needs be, but I need to get a better handle on the android stuff, and just see if it becomes a problem I guess [14:05:05] <plars> so we can carry over the action until then, or just reinstate it later if needs be [14:05:22] <plars> [TOPIC] Engineer progress reports [14:05:27] <lool> Sorry, I'm not sure what we meant there anymore :-( [14:05:49] <plars> lool: it's ok, I'll ping you about it sometime in the future if it becomes a problem [14:05:54] <lool> Ok [14:05:58] <plars> too early to know for sure [14:06:21] <plars> springz: why don't you go first, you've made some good progress on the dispatcher this week I know [14:06:39] <springz> ok [14:06:56] <springz> test-abrek implementation merged, merged a prompt matching string patch like master_str and tester_str [14:07:10] <springz> Set up a l-c server, and start working on submit_results with Launch Control, not finish yet [14:07:30] <springz> I'll do a dispatcher integration test on imx51evk tonight [14:07:37] <springz> investigate the power auto boot up workaround for MX53 QuickStart/LOCO board [14:08:19] <springz> plars, can we do rework for mx53 in cambridge? [14:08:30] <plars> springz: I don't know, I need to check on that [14:08:43] <plars> springz: it's something that we normally wouldn't do [14:08:53] <plars> springz: unless we have someone local who is really comfortable doing that [14:08:55] <springz> plars, when should MX53 ready [14:09:05] <plars> springz: otherwise, is it possible that maybe we could swap it for a reworked one? [14:09:29] <springz> plars, maybe, please ask freescale window [14:09:38] <plars> springz: well, it's set up now, but in the process of setting it up, they discovered that this was an issue [14:09:39] <davepigott> I'm here in Cambridge. With some guidance I'm happy to help [14:09:57] <plars> davepigott: the question, is if you are comfortable reworking a board [14:10:03] <springz> davepigott, it needs some rework [14:10:08] <plars> davepigott: my understanding is that it would mean soldering a few capacitors on it [14:10:18] <springz> right [14:10:41] <plars> davepigott: unless you've done lots of this before, and are really comfortable, I'd feel better about us talking to freescale about getting a reworked one to swap for this [14:10:56] <davepigott> Hmm. I have been known to use a soldering iron, but it's surface mount and could be problem for me [14:11:01] <plars> yeah [14:11:26] * plars will take an action to chase that down [14:11:29] <plars> or actually [14:11:41] <plars> I'll give it to JamieBennett, because he's not here to defend himself yet :) [14:11:48] <davepigott> :) [14:11:49] <springz> plars, davepigott not very complicated, we can wait for the steps [14:11:58] <plars> [ACTION] JamieBennett to see if freescale can get us a reworked imx53 [14:12:16] * JamieBennett is now back [14:12:16] <plars> heh [14:12:21] <plars> oh, good timing [14:12:29] <plars> I had 10 more things to action you with in the queue :) [14:12:34] * JamieBennett reads backscroll [14:12:37] <plars> heh heh [14:12:41] <plars> j/k [14:13:06] <plars> JamieBennett: basically, we discovered that the imx53 loco boards do not power on when you restore power to them [14:13:21] <JamieBennett> ah, so its a hardware issue? [14:13:26] <davepigott> yep [14:13:33] <plars> which means, that if we ever have to trigger a hardreset of the board in the lab, our hard reset function will be to send davepigott an email to go press the reset button [14:13:38] <plars> which is not very automated [14:13:44] <springz> JamieBennett, no, the design doesn't consider this requirement [14:13:45] <plars> and will probably just frustrate dave [14:13:48] <plars> :) [14:13:53] <JamieBennett> :) [14:14:04] <davepigott> Happy to do it in the short term, long term, blah [14:14:08] <springz> JamieBennett, freescale HW guy is working on workaround solution, help it come soon [14:14:09] <plars> springz has checked with the hw guys at freescale, who have a solution, but requires some minor rework on the board [14:14:46] <JamieBennett> OK, can you cc me on the email with this information and I'll continue to monitor? [14:14:48] <plars> instead of us trying not to butcher the board, I was hoping we could check with freescale, if they would be willing to rework one for us and send it to us [14:14:52] <plars> will do [14:15:05] <JamieBennett> great, I'll look into that [14:15:21] <plars> [ACTION] plars or springz to forward imx53 rework info to JamieBennett [14:15:40] <plars> thanks springz [14:15:46] <plars> anything else you wanted to add? [14:15:54] <springz> no [14:15:57] <plars> ok [14:16:06] <plars> for my bit [14:16:31] <plars> spent some time helping davepigott with the lab issues, which I'm sure he'll mention in a bit [14:16:43] <plars> some testing on launch-control, found some issues under natty [14:16:50] <plars> working pretty well under maverick though [14:17:10] <plars> and if you didn't know already, we have a demo deployment of it at http://validation.linaro.org/launch-control [14:17:25] <plars> which should usually be running pretty much the latest working version [14:17:45] <springz> can i push stream to it? [14:17:47] <plars> dashboard.linaro.org will be the "official" repository, and updating it is in the works as soon as zyga gets back [14:17:50] <plars> springz: yes [14:18:20] <plars> also I updated abrek to work with the latest json requirements in dashboard, so you should be able to push from abrek now too [14:18:32] <springz> plars, great, I don't need to modify the config in the job.json [14:18:44] <plars> The really cool thing, is that I did a full run of everything we have in the dispatcher last night, IN the validation lab on panda02 [14:18:56] <JamieBennett> \o/ [14:19:05] <plars> I created a job control file to have it pull an image/hwpack, deploy, install abrek, and run stream [14:19:13] <springz> plars, did you see zyga recent abrek code change [14:19:25] <plars> (springz is currently working on the pieces to publish the results, so that part wasn't included) [14:19:42] <plars> after several try/tweak iterations, it works [14:19:50] <plars> not too many changes were needed, just a few minor things [14:19:54] <plars> I'll push those in shortly [14:20:02] <springz> cool [14:20:52] <plars> So the plan is, that once we have all the pieces of the dispatcher in place, we'll need to adapt a bit of the glue that I worked on before to find the latest image/hwpack, and submit a job containing that to several of the boards [14:20:59] <plars> we can do that from jenkins for the time being [14:21:12] <plars> and just have some canned jobs like that running periodically, and actually producing results [14:21:28] <plars> which will be a good step up from the daily image booting we are doing now [14:22:01] <plars> in parallel, the scheduler development will push forward, and hopefully soon give us something we can use there to queue these things up, and have recurring jobs [14:22:29] <plars> mirsad: which brings us to you, I know you made some scheduler progress this week, want to fill everyone in? [14:23:12] <mirsad> plars, yes, my modest progress is that scheduler-models was merged yesterday [14:23:37] <mirsad> so we have hopefully the database part ready [14:24:06] <springz> mirsad, which db you are using now? [14:24:36] <plars> it's django, so it should be able to accommodate several [14:24:57] <mirsad> springz, currenlty sqlite, but I will go to postgresql soon, just to have production-like environment locally [14:24:58] <plars> I've tested it with sqlite, but there should be no issue with using postgres for production [14:25:20] <mirsad> yes, development part will still use sqlite [14:26:11] <mirsad> but as plars says, no difference for django, just configure it correctly and you can run any db [14:26:21] <springz> yep [14:26:47] <plars> mirsad: what are your plans for this week with the scheduler? what's next? [14:27:09] <mirsad> next is the daemon part, just to be able to pick up a job and run it in dispatcher [14:27:58] <plars> mirsad: I have some ideas on that [14:28:11] <plars> mirsad: but I was also curious about my comment in the mp that you never responded to [14:28:20] <mirsad> plars, what is that_ [14:28:20] <plars> about how to deal with multiple tests [14:28:47] <mirsad> aha, ok, I said it will be done when fixing JSON creation class [14:28:49] <plars> if you have the json sections just stored with the testsuite, how will you combine them for the install part? [14:28:53] <plars> ok [14:28:58] <plars> I missed that I guess [14:29:07] <plars> I think the ui could use some help too [14:29:24] <plars> there are some rough edges, but we have a basic framework we can work off of now [14:29:29] <plars> and improve [14:29:32] <mirsad> plars, sure, there is a WI for that [14:29:41] <plars> anything else? [14:29:59] <mirsad> nope, I just helped ChiThu initially today [14:30:10] <plars> thanks for that! [14:30:27] <plars> So everyone meet ChiThu [14:30:32] <plars> He's just getting started [14:30:44] <davepigott> ChiThu: Hi! Welcome. [14:30:45] <ChiThu> Hi everybody [14:30:54] <JamieBennett> hi [14:30:56] <plars> joining us from STE, to work on the automated validation team [14:30:59] <springz> ChiThu, welcome [14:31:13] <ChiThu> Thank you. I have a lot of stuff to read. [14:31:35] <plars> ChiThu has been involved in many of the automation projects they have, and brings a lot of background in this area [14:31:38] <ChiThu> Mirsad is helping me. [14:32:33] <plars> ChiThu: Since you are just getting set up right now, feel free to skip this part, but for next week, I'll send you the link to the status page for you to update [14:33:03] <plars> Also, we have davepigott joining us this week in Cambridge, UK [14:33:06] <ChiThu> Yes. Next week I will be synch [14:33:21] <mirsad> davepigott, welcome! [14:33:30] <plars> Who has already had a trial by fire, with the router dying on us in the lab [14:33:42] <davepigott> Hi everyone! [14:34:01] <davepigott> lol - Yes. And still giving us trouble, but only internally at least [14:34:07] <plars> But davepigott also has a lot of experience with creating automated testing frameworks for ARM systems, and brings a wealth of related experience here [14:34:45] <plars> So he'll have to wear two hats from time to time, and help get things sorted out with the equipment we have in the lab, but hopefully that will be infrequent once we get it all going [14:35:08] <plars> davepigott: do you have anything you want to add here? [14:35:18] <davepigott> Couple of things [14:36:26] <davepigott> Basically, as plars says, I've picked up the mantle of local sys-admin, remote boot button presser as well as the other duties. In that time I've agreed locally that we need to change our net topology here [14:36:56] <plars> indeed [14:37:05] <davepigott> This will mean that at some point in the future we will have a few hours of down time, but the benefits will be huge. Planning on making it a weekend to minimise disruption [14:37:05] <davepigott> \ [14:37:23] <davepigott> Will give plenty of notice, I promise! [14:38:05] <davepigott> So the validation boards will have their own sub-net, separate to the office net, and we'll get a new router in. [14:38:06] <springz> davepigott, is your office right in validation farm room? [14:38:14] <davepigott> Yep [14:39:21] <plars> anything else? [14:39:28] <davepigott> Other than that, I've been setting up the imx53 board with DaveM, learning the ropes and getting to meet people. :) [14:40:25] <davepigott> That's my lot for now [14:40:28] <plars> davepigott: if you haven't yet, I'd also like you to start taking a look at the blueprints I forwarded to you, and the code for lava, launch-control, abrek, etc [14:40:35] <plars> so that you can start getting familiar with those [14:40:41] <plars> we'll talk more about that later though [14:40:57] <davepigott> Yep. Now that things are a little more settled here, that's next on my list. [14:40:58] <davepigott> Cool [14:41:06] <plars> [TOPIC] Work Item progress and team issues discussion [14:41:10] <plars> http://status.linaro.org/linaro-validation.html [14:42:19] <plars> We had a lot of flat at the beginning of the week, but due to the progress on the scheduler, dispatcher, and a few other random things recently, we were able to kill some work items still [14:42:53] <plars> hopefully this trend will be able to accelerate even more now that we are getting more unblocked there, and have two new people joining us :) [14:43:08] <plars> but for the current items, is anyone blocked on anything? [14:43:33] <davepigott> Nothing blocking [14:44:03] <plars> JamieBennett: did you have any questions here? [14:44:14] <JamieBennett> not at the moment [14:44:24] <JamieBennett> I think we are on the right track [14:44:31] <plars> good [14:44:39] <plars> [TOPIC] AOB [14:44:56] <plars> any other business? anyone have anything to add? [14:45:45] <ChiThu> Just got info from Mirsad that you have remove the RabbitMQ and the Celery. [14:46:03] <ChiThu> Short summary the reason why ? [14:46:09] <plars> ChiThu: it was never really a part of it yet, it was just an idea of something we might want to look at [14:46:22] <plars> ChiThu: but there were never any proposals on how to actually implement it using that [14:46:39] <plars> ChiThu: if you have strong feelings about it, please feel free to introduce a solution using that [14:47:46] <plars> ChiThu: in theory, this was one possibility that could be used by the scheduler daemon to collect jobs from the scheduler and run the dispatcher on those jobs [14:47:47] <ChiThu> I need first tol understand the current implementation and come back with ideas for comming releases [14:48:06] <plars> ok, we can talk more about it later too if you'd like [14:48:29] <ChiThu> yes, I am happy with the answers for now. [14:48:42] <plars> Ok, anything else? [14:48:56] <plars> if not, we can finish > 10 min. early :) [14:49:41] <davepigott> I'm kopacetic. :) [14:49:43] <plars> ok, have a good (morning || afternoon || evening) everyone :) [14:49:49] <plars> #stopmeeting [14:49:54] <plars> err [14:49:56] * plars fails [14:49:58] <plars> #endmeeting Meeting ended.
internal/archive/Platform/LAVA/Meetings/2011-03-24 (last modified 2013-08-23 13:19:23)