<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">Paul, </div><div class="gmail_extra"><br></div><div><br></div><div class="gmail_quote">On Fri, Nov 29, 2013 at 4:58 PM, Paul Eggleton <span dir="ltr"><<a href="mailto:paul.eggleton@linux.intel.com" target="_blank">paul.eggleton@linux.intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1hk" style="overflow:hidden">LAVA<br>
-----<br>
<br>
A number of people had suggested I look at LAVA [1]. It is split into different<br>
components for each function, some of which should be usable independently so<br>
you don't have to use the entire framework. Many of the components could be<br>
useful assuming they are independent, but in terms of being able to actually<br>
run our tests, the one that stands out as being most relevant is lava-<br>
dispatcher. This is the component that deploys images, and boots the hardware<br>
in order to run the tests.<br>
<br>
I've looked at lava-dispatcher a couple of times; firstly at the code, and<br>
yesterday I looked at actually running it. Initially it looked very promising<br>
- reasonably licensed, written in Python, has some rudimentary support for OE<br>
images. However while looking at it I found the following:<br>
<br>
* It requires root to run, since it mounts the images temporarily and modifies<br>
the contents. We've done quite a lot to avoid having to run as root in OE, so<br>
this is a hard sell.<br></div></blockquote><div><br></div><div>i have forwarded this email to the relevant people in Linaro working on LAVA. I hope to be able to bring more information about that, as I am not involved with LAVA, just a 'user' of it. By 'root' here, you mean on the server side, e.g. the LAVA instance, which will typically not be the 'builder', or do you want to couple build and test on the same 'server'? LAVA jobs are generally submitted by a CI instance (Jenkins in our case). </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1hk" style="overflow:hidden">
<br>
* It expects images to be created by linaro-media-create, which in turn<br>
requires an "hwpack" [2]. The hwpack concept seems primarily geared to Ubuntu<br>
and distributions like it where you'd have a generic base image upon which<br>
you'd install some board-specific packages in order to make it work on the<br>
board. OE doesn't work that way - we just build images specific to the board,<br>
which makes this mechanism completely superfluous for our usage; but the tool<br>
appears to require it.<br></div></blockquote><div><br></div><div>that is no longer the case. we do have support for 'native' OE images, and we've had that for a while. That is what I am using for my project at Linaro. None of our projects/jobs deliverable are 'public' at the moment, so you won't find them, but i can confirm that what we deploy for our jobs is the output of OE (e.g. what is in the deploy/image folder). hwpack was something mostly meant to make it simpler to work with Ubuntu and Android root FS, and is not suited for OE.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1hk" style="overflow:hidden">
<br>
* There is a general lack of abstraction and far too much hardcoding. For<br>
example, even at the most abstract level, the "Target" class (which is the<br>
base class for defining what to do for different types of targets) has hardcoded<br>
deploy_linaro / deploy_android functions:<br>
<br>
<a href="https://git.linaro.org/gitweb?p=lava/lava-dispatcher.git;a=blob;f=lava_dispatcher/device/target.py" target="_blank">https://git.linaro.org/gitweb?p=lava/lava-dispatcher.git;a=blob;f=lava_dispatcher/device/target.py</a><br>
<br>
* It's not clear to me how well it will work across different host<br>
distributions that we want to support; the main LAVA installer quits if it<br>
isn't run on Ubuntu. For convenience I happened to be using an Ubuntu VM, and<br>
I wasn't running the full installer so I avoided this check altogether. It<br>
just concerns me that such a check would even be there.<br></div></blockquote><div><br></div><div>I agree that this is a problem and we should fix. Our IT infrastructure is largely based on Ubuntu servers, but that should not affect what we create that much.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1hk" style="overflow:hidden">
<br>
Of course, none of these problems are impossible to overcome, if we're<br>
prepared to put a significant amount of engineering into resolving them. In<br>
terms of enabling the Yocto Project QA team to test images on real hardware in<br>
the 1.6 development cycle however, I don't believe this is going to be<br>
deliverable.</div></blockquote></div><br></div><div class="gmail_extra"><br></div></div>