[Automated-testing] LAVA Intro presentation
William Mills
wmills at ti.com
Thu Jan 30 08:08:13 PST 2014
So last Friday we suggested a follow up meeting this Friday.
(I apologize for trying to do this again on little notice. I was
travelling for meetings M-W)
I think this is worthwhile _if_:
Darren, Paul, Richard, Tyler, & Alan all attend.
We can do one of the following:
* Articulate a starting use case or case(s)
* Have concert follow up questions to the last meeting/video
* Have input from LTSI about the problem they had
Do any of the following timeslots work (in preference order)
1) Friday Jan 31, 9 am | noon | 17:00 UK
2) Friday Jan 31, 10 am | 1pm | 18:00 UK
3) Friday Jan 31, 8am | 11 am | 16:00 UK
If a meeting does not happen tomorrow I suggest we start these topics
here in e-mail and then have a conf call later next week.
Bill
On 01/24/2014 03:59 PM, William Mills wrote:
> jinks.
>
>
> On 01/24/2014 03:57 PM, Alan Bennett wrote:
>> All;
>> For those that missed the event, you can find the recording @
>> http://youtu.be/ZpKRz9-SMGA
>>
>> The "raw" meeting notes can also be found in the Google document:
>> http://goo.gl/IZUtzY
>>
>> Alan
>>
>>
>> On 24 January 2014 12:50, Darren Hart <dvhart at linux.intel.com
>> <mailto:dvhart at linux.intel.com>> wrote:
>>
>> On Fri, 2014-01-24 at 20:52 +0100, Bird, Tim wrote:
>> > Hi everyone,
>> >
>> > I'm really sorry I missed this event, as I was very interested
>> in comparing LAVA to Cogent's
>> > current systems (as I understand them), and to my own systems.
>> >
>>
>> Similarly for me as well. There were some workflow and integration
>> concerns I wanted to discuss and how Lava compared to Autotest in this
>> respect.
>>
>> For example: what facilities exist in Lava for target management?
>> Consoles? Logs? Power control? I use conmux for this with Autotest.
>>
>> This unfortunately landed in the middle of some very heavy churn
>> for me
>> in a number of areas, and it would have been difficult to make the
>> discussion even had I received the invite yesterday. Can we work
>> to have
>> a few days notice for things like this in the future?
>>
>> I'm particularly disappointed to have missed it as I was the one that
>> requested it.
>>
>> Thanks,
>>
>> Darren
>>
>> > Were any answers provided to the questions below? If so, could
>> they be posted somewhere
>> > for review? I think we discussed setting up a page on the Yocto
>> Project wiki about
>> > this effort. Has anyone done that yet?
>> >
>> > Thanks,
>> > -- Tim
>> >
>> >
>> > On Friday, January 24, 2014 8:48 AM,
>> automated-testing-bounces at yoctoproject.org
>> <mailto:automated-testing-bounces at yoctoproject.org> On Behalf Of
>> William Mills wrote:
>> > >
>> > > Here are my starter question.
>> > > (Some of these I now know but I had these question a year ago
>> when we
>> > > started looking.)
>> > >
>> > > 1) Is LAVA suitable for personal machine deployments?
>> > >
>> > > I think the initial focus of this project should be a board lab
>> > > environment. This seems to be the natural environment of LAVA.
>> > >
>> > > That said, I think the Yocto Project recommended test tool
>> should scale
>> > > down to situations where a developer has a board attached to
>> her PC
>> > > where she does bitbake builds and then runs test locally.
>> > >
>> > > What issues do you see for LAVA in this situation?
>> > >
>> > > 2) We want to test images as produced by bitbake, can we do
>> that with LAVA?
>> > >
>> > > For Ubuntu and other distros, LAVA uses a tool at test start
>> to combine
>> > > a generic image and a hw specific add on. Bitbake already
>> does this.
>> > >
>> > > Can we bypass this step and test the images just as they were
>> produced
>> > > from bitbake? Do you already have examples of this working?
>> > >
>> > > 3) What types of image deployment / boot can you support?
>> > >
>> > > The traditional LAVA image deployment is to use multiple
>> partitions on a
>> > > boot storage device: a master image and a test image. I
>> believe LAVA
>> > > controls the boot process over a serial port to direct the
>> boot flow to
>> > > the master or test partition.
>> > >
>> > > What other scenarios do you support and do you have examples
>> of these
>> > > working already?
>> > >
>> > > * Network boot of kernel & standalone initramfs?
>> > > * Network boot of kernel w/ NFS root?
>> > > * SDMUX based boot from one of two SD cards based on
>> dispatcher control?
>> > > * BBB bootmode can be controlled via a Ethernet controlled
>> relay board,
>> > > can LAVA supoprt that?
>> > > * others?
>> > >
>> > > 4) Yocto Project supports ARM, x86, MIPS, and PowerPC
>> architectures. Is
>> > > that an issue for LAVA?
>> > >
>> > > We are starting with BeagleBoneBlack (ARMv7) and Minnow board
>> (x86) but
>> > > will eventually want to cover all the architectures. YP test
>> > > infrastructure users will want to add their own boards.
>> > >
>> > > How hard is this?
>> > > Is LAVA flexibility enough to control various boards?
>> > >
>> > > 5) What is the size of the team that works on LAVA? How many
>> people are
>> > > using outside of the linaro.org <http://linaro.org> LAB?
>> > _______________________________________________
>> > automated-testing mailing list
>> > automated-testing at yoctoproject.org
>> <mailto:automated-testing at yoctoproject.org>
>> > https://lists.yoctoproject.org/listinfo/automated-testing
>>
>>
>>
>>
>>
>> --
>>
>> Alan Bennett, Engineering Manager, Linaro LAVA Team
>> Linaro.org <http://www.linaro.org/>***│ *Open source software for ARM
>> SoCs | Follow Linaro*:*Facebook
>> <http://www.facebook.com/pages/Linaro> | Twitter
>> <http://twitter.com/#%21/linaroorg> | Blog
>> <http://www.linaro.org/linaro-blog/>
>> irc: akbennett | alan.bennett at linaro.org
>> <mailto:alan.bennett at linaro.org> | linaro-validation at lists.linaro.org
>> <mailto:linaro-validation at lists.linaro.org>
>>
>
>
>
> _______________________________________________
> automated-testing mailing list
> automated-testing at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/automated-testing
>
More information about the automated-testing
mailing list