[Automated-testing] LAVA Intro presentation

[Darren Hart]

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 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 LAB?
> _______________________________________________
> automated-testing mailing list
> automated-testing at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/automated-testing