Thanks for the input! This information is always of value. A few comments inline:

On 06/07/2012 05:06 PM, William Mills wrote:

All,

Last week (mostly the weekend) I started a project to set up my own lava instance. I use EC2 for this sort of thing so I don't trash my own systems.

Below is a walk through of my experience. Take it for what it is worth.

I did get something running at http://test3.arago-project.org/ I'll leave it running over the weekend.

I was hoping to do this all again clean but that does not look like it will happen anytime soon. Rather than letting this get stale, I will share it in its rather "raw" form.

0. What Ubuntu version?

I started with 12.04 but Lava seems to default to python2.6 and that is not even an install candidate in 12.04 so I backed up to 11.10. Not sure if it really matters or not as the virtualenv seems to have used 2.7 even though lava-deployment-tool hard codes 2.6. Did not figure out what was going on there.

Interesting. I run on 12.04 at home so I'm not sure what happened.

1. lava-tool, lava-scheduler-tool, do not work behind an http proxy

workaround: go home to play w/ lava

This is a known bug: https://bugs.launchpad.net/lava-tool/+bug/898174

2. lava-deployment-tool does not handle uwsgi download correctly

tarball has moved to old/ some places fixed others not workaround: patch to centralize definition better fix: look in both "" and "/old" better'ist fix: also move this to bundle (otherwise this defeats the whole purpose of all the bundle overhead)

Thanks - this has now been fixed.

3. lava-deployment-tool wizards are a pain in the neck

better fix: have separate config step that creates values install then takes bundle and config

Yes - we are starting to feel the same way and are thinking about trying to improve this if we can find the time.

4. no admin account and don't know how to install

instructions tell you to login to admin but no info on how to lava-deployment-tool manage test1 createsuperuser example should give URL for those not familiar with django conventions

good point

5. deployment does not enable https:// protocol but examples use it

hack workaround: use http: for everything shouldn't things that require authorization only work over https://?? at least as an option?

good feedback. This is an area that has been hard for the team. We are trying to make LAVA more "product" friendly and not just a Linaro service.

6. need to add schedule job permissions for users

prerequisite: login to site w/ your launchpad account log in to site admin w/ superuser account find your launchpad account in Users add scheduler* permissions better fix: create labuser and labadmin groups and give appropriate permissions to each, then just add users to appropriate group

7. keyring.core needed but not available

source /srv/lava/instances/test1/bin/activate pip install keyring deactivate

8. no devicetypes

docs talk about adding device but does not say you need to add device type as well cant add a device w/o first adding a device type dashboard has a device type also, do I need to add there as well? [Seems like No]

There are two places this is done:

lava-dispatcher (file based configs) - from here a device type is not required, but is handy because it makes the config for each device much smaller

lava-scheduler app (django) - From here you must define a device type because each device needs to point to what device type it belongs to. This is used for grouping things in our UI.

what about kernel ci? this all seams very manual (tried to submit without any device or device type, did get 404 error) in django admin panel under scheduler add device type panda

I've never set this up locally. Michael may have tips for this.

[can submit a job now]

9. added device config file to wrong directory, needs to go into

/srv/lava/instances/test1/etc/lava-dispatcher/devices/ not up one level

10. need to install conmux, & missing dependency liburi-perl

(for real HW this would be needed. I got it working but it was not clear where they got the apc control app from and how it was configured. need command hardreset)

[switched to qemu focus]

11. Add beagle-xm device type & beagle-xm01 device to scheduler

add devices/beagle-xm01.conf device_type = beagle-xm hostname = beagle-xm01 client_type = qemu

12. download of hwpack and rootfs not working

getting html for root dir of release server wget of same url works ok on same machine I suspect that url2 opener does not handle redirects that releases.linaro.com make the user do (even thought wget works fine) squid proxy probably hides this from dispatcher result: squid is not really optional workaround: put copy of images needed into my /images/ref dir and change job to refer to those. works

This is because of the click-through license stuff on releases.linaro.org. The urllib2 API in python doesn't handle this well. Your workaround is pretty sensible.

13. need to install qemu

installed qemu-user-static and qemu-system supported -M beaglexm however, EC2 tiny instance does not have enough memory to allocate 512M RAM qemu-system-arm won't honor a -m 128 w/ a -M beaglexm in either order (I consider that a bug) installed 4GB swap file and got past this. (booting linaro image on qemu did not cause any noticeable swapping)

14. qemu command does not work

default_qemu_command was qemu, set it to qemu-system-arm in beagle-xm01.conf (should be in beagle-xm.conf)

15. qemu boot times out in udev or wait for root.

EC2 tiny instance is probably too underpowered to run this Need to start over with a bigger machine

Bill

---

linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation