linaro-validation September 2012

linaro-validation@lists.linaro.org

15 participants
37 discussions

Re: [Linaro-validation] software context/source references feature in LAVA

by Zygmunt Krynicki

W dniu 14.09.2012 16:46, Andy Doan pisze: > On 09/14/2012 09:41 AM, Zygmunt Krynicki wrote: >> W dniu 14.09.2012 16:31, Andy Doan pisze: >>> On 09/12/2012 08:39 PM, Michael Hudson-Doyle wrote: >>>> Andy wrote [quoting went funny somewhere]: >>>> >>>>> Here's a way we could do this in lava-test: >>>>> >>>>> <http://bazaar.launchpad.net/~doanac/lava-test/software.sources-support/revi…> >>>>> >>>>> >>>>> >>>>> >>>>> Its minimal overhead (basically none) for the test itself. However, >>>>> Michael may find it a bit odd how a bolted it on to our framework. >>>>> Thoughts? >>>> >>>> Seems kind of OK. I don't think I have deep conceptual insight into >>>> the >>>> problem being solved here though :-) >>> >>> Yesterday during the LAVA team meeting, we came up with a better way to >>> do this in code. It still doesn't cover the "99%" case, but it makes >>> things more transparent to the test-definition. MP to follow soon. >> >> Cool, could you briefly describe this? > > Basically add something to the installer action that lets it clone repos > rather than having be some command in the testdef we are unaware of. +1 that's saner. I'm worried about the lack of sensible API for stages such as this to feed this information deeper into the core (to the initial bundle to be precise) PS: CCing the list again ZK -- Zygmunt Krynicki s/Linaro Validation Team/Canonical Certification Team/ s/Validation/Android/

13 years

software context/source references feature in LAVA

by Fathi Boudra

move the discussion to the ml. ---------- Forwarded message ---------- On 09/11/2012 10:22 AM, Fathi Boudra wrote: >> >> 3.2) knowing the test source. I found this pretty interesting and did some >> >poking around. We have the concept of a "software context" in LAVA: >> > >> ><http://validation.linaro.org/lava-server/dashboard/streams/private/team/lin…> >> > >> >However, as it stands, we only populate it with dpkg information. Even if >> >your core test code was a package, I've seen enough threads on going from >> >package to source on linaro-dev that I'll assume that's useless. Within the >> >software context we have a structure that currently unused called "software >> >sources". I think this would enable drilling down to what you are after. >> > >> >The big question is*how* we populate that information. Based on the >> >> >I think we would want to add some field where you could >> >pass this to the Test object you create. That would be pretty simple. I'm >> >not sure if that would be ideal which is why I added Michael to the thread. >> > >> >So, just to make sure: does addressing 3.2 first make sense? > > It make sense. If we want to track the test sources, we want the software > context/source references feature. > Now, how can we populate it (Project/VCS/branch/tag or revision)? > Here's a way we could do this in lava-test: <http://bazaar.launchpad.net/~doanac/lava-test/software.sources-support/revi…> Its minimal overhead (basically none) for the test itself. However, Michael may find it a bit odd how a bolted it on to our framework. Thoughts?

13 years

Leased line status

by Dave Pigott

Hi all, Just to let you know that we've hit some technical issues, and so v.l.o is still down for the moment. Zen (the ISP) are working on fixing it, but I have no ETA for the moment. If the issues can not be resolved by close of play today, I will be putting the ADSL line back on. I'll keep you posted. Thanks Dave Dave Pigott Validation Engineer T: +44 1223 40 00 63 | M +44 7940 45 93 44 Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

13 years

Scheduled downtime

by Dave Pigott

Hi all, The path is never simple. Zen scheduled a set up call for 10AM this morning and then didn't call. I sent an e-mail complaining and the work has now been re-scheduled for 10AM tomorrow. Many apologies for the inconvenience. Thanks Dave Dave Pigott Validation Engineer T: +44 1223 40 00 63 | M +44 7940 45 93 44 Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

13 years

Follow up

by Dave Pigott

Hi Mark, It was really useful for me to meet up and present to you guys yesterday, and I hope, likewise, that they found it useful. As per our conversation, here is the list of resources for Linaro: Linaro wiki: wiki.linaro.org LAVA web site: validation.linaro.org Daily code snapshots: snapshots.linaro.org Linaro releases: releases.linaro.org Android build: android-build.linaro.org You can get all the information for our Copenhagen Connect event here: http://connect.linaro.org/events/event/lce12-copenhagen/ Finally, the validation mailing list is linaro-validation(a)lists.linaro.org Please pass this on to all those who attended the meeting. Secondly, I'd love to come and do a lunch and learn on LAVA. Let me know when is a good time, and try to give me a couple of weeks notice! Good to see you, and thanks again Dave Dave Pigott Validation Engineer T: +44 1223 40 00 63 | M +44 7940 45 93 44 Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

13 years

LAVA Weekly Meeting Time

by Andy Doan

As you know the LAVA team currently has alternating weekly meeting times. The intent was to have one that worked well for our team members in Asian timezones and one that worked well for European/American timezones. We now have no one working in an official capacity in Asian, so that meeting time has become just about useless. I'd like to recommend change the current bi-weekly meeting time from: Friday 01:00 UTC to: Thursday 20:00 UTC This would work well because Michael, Antonio and myself could attend this slot. The other meeting time on Fridays at 13:00 UTC will continue to work well since Antonio, Dave, and myself. Any objections? -andy

13 years

update to linaro's lava staging server

by Andy Doan

Thanks to Dave's work on cloud deployment, I've been able to move our staging instance of LAVA off of our production server and onto a cloud instance in our lab. In theory, everything should "just work". However, I'm sure there will be hiccups. One thing I've noted is that I wasn't able to get the old deployment-report.xhtml showing, and I didn't have the patience to fight Apache conf files. Currently people that are members of ~linaro-validation have access to this new cloud node. If you need access let me know and I'll set something up for you. Also, I've backed up the old staging instance (to the usual place on our NAS) and have deleted the instance from control. Nothing like having an incompetent manager break everything while headed into a weekend! :) -andy

13 years

Scheduled downtime

by Dave Pigott

Dear all, The time has finally come when our leased line is going to go live on validation.linaro.org! We've scheduled with the supplier to do the switchover on Wednesday morning and, as long as things go according to plan, which they haven't so far, then the outage disruption could be less than 60 seconds. But the best laid plans of mice and men tend to go awry, and so I am sending out a warning that validation.linaro.org may be unavailable for up to 24 hours, because if nothing else, it will take time for the new IP address to filter through to all the name servers. For those interested on the technical spec of the install, we have a 10Mb fibre connection on a 100Mb dedicated backbone, with the old ADSL connection acting as an automatic failover as a backup. We're being quoted 100% uptime, with penalties applied for any downtime. I've also been told that the 10Mb is flexible and it will allow us to peak above that but, if we do it too often, they'll warn us and then we can negotiate an up in the rate. Here's looking to a much faster, more reliable LAVA interface to the world. Thanks Dave ------------------------------------------------------------------------ Dave Pigott Validation Engineer T: +44 1223 40 00 63 | M +44 7940 45 93 44 Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ------------------------------------------------------------------------

13 years

Vexpress-a501

by Dave Pigott

On 17 Jul 2012, at 21:15, Ryan Harkin wrote: > Hi Dave, > > 5) A5 and board naming. > > I was talking to Scott about all this earlier today. He is keen that we get this TC2 board up and running, but he's also keen that we replace one of the A9 core tiles with the A5 tile - now that the A9 has stabilised. This is a commitment we made to ARM a long time ago and I've been putting it off while we had 1 x A9 playing up on us. > > Scott and I discussed naming conventions and we were thinking that the numbering would be best on a per board type rather than overall vexpresses. Eg, we would have 3 boards: > > vexpress-a501 > vexpress-a901 > vexpress-tc201 Hi Ryan, Now that I am close to having the A5 booting in the lab, we need to discuss this issue, as we did with the panda. Basically, with the panda, Scott and I originally settled on them having a common device type, with a device_tag of either 4430 or 4460, and then naming the device instances as pandaXX and panda-esXX. However, this was later changed so that we have two distinct devices, panda and panda-es, since people will want to test on a specific platform, and know that they are, rather than the situation as it would have been, in that if you didn't specify a device tag, the job would run on any panda - 4430 or 4460. It was felt that this was less than desirable. So what I'm suggesting is, that we create three device types, viz: vexpress-a5 vexpress-a9 vexpress-tc2 And then it's clear when you submit a job it's clear which device type you will run on, rather than, as in the panda case above, submitting to vexpress and not knowing which type is being targeted. N.B. I am aware of the need/desire to be able to submit one job to lava and then have it run across all device variants, but that is orthogonal to this argument since, if we do implement such a feature, a device set would probably be defined, i.e. rather than saying "one each of vexpress variants" you would specify "vexpress-a5, vexpress-a9, vexpress-tc2", or indeed "panda, panda-es". Just to be clear, is that what you were suggesting as well? Brickbats and suggestions? Thanks Dave

13 years, 1 month

Re: [Linaro-validation] Usage of deploy linaro image

by Andy Doan

On 09/05/2012 11:17 PM, Prakash Ranjan wrote: > And what does the image paramter contains? Is it containg any > kernel image, or rootfs image or both? > > Can you please give tell me one example using a short job file. > The image parameter can be used if you have a pre-built image rather than making the dispatcher run linaro-media-create on a hwpack+RFS. Here's an example for qemu that can be applied to anything else: <http://lava.readthedocs.org/en/latest/qemu-deploy.html#configure-the-dispat…>

13 years, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

linaro-validation September 2012