Upgrade to Lava 2019.11

[pfalcon]

This is mostly a straightforward update, cherry-picking upstream commits. However, upstream docker images have upgraded to Debian Buster. It required updates to some package installed on our side.

I've tested this with example/ micropython-interactive.job, micropython-interactive-qemu-zephyr.job, lava.job (frdm_k64f), everything works as expected. Would be nice if other folks tested it with their boards/jobs.

[pfalcon]

cc @edmooring

[vanti]

Do you have a corresponding update for lite-lava?

[pfalcon]

Do you have a corresponding update for lite-lava?

Well, lite-lava (https://github.com/Linaro/lite-lava) isn't directly related to this upgrade, the setup by default uses upstream's docker images for LAVA, not source code.

[vanti]

Do you have a corresponding update for lite-lava?

Well, lite-lava (https://github.com/Linaro/lite-lava) isn't directly related to this upgrade, the setup by default uses upstream's docker images for LAVA, not source code.

Just curious since some of us making changes to LAVA have set up bindings to it. But arguably once our changes have been upstreamed we should be able to to just switch back to using the default setup.

I am able to launch a job on cc3220sf_launchxl and cc1352r1_launchxl after the upgrade, but not without running 'make clean'. Do you know of a way to upgrade without nuking the database (in case there are test results I care about)?

Also I noticed that test jobs pointing to remote urls (e.g. https://snapshots.linaro.org/components/kernel/zephyr/master/zephyr/frdm_k64f/4563/tests/subsys/logging/log_list/logging.log_list/zephyr/zephyr.bin) no longer work. I think they did at some point in time. I am now getting an error when downloading the file:

[vanti]

Also I noticed that test jobs pointing to remote urls (e.g. https://snapshots.linaro.org/components/kernel/zephyr/master/zephyr/frdm_k64f/4563/tests/subsys/logging/log_list/logging.log_list/zephyr/zephyr.bin) no longer work. I think they did at some point in time.

Scratch that last part of my comment. It dawned on me I am missing some proxy settings that I inadvertently removed while getting rid of the lite-lava bindings. It works now.

[pfalcon]

Just curious since some of us making changes to LAVA have set up bindings to it.

Yes, myself including. But this setup should recommended be structured/hierarchical, as described here: https://collaborate.linaro.org/pages/viewpage.action?pageId=118293253#GettingStartedwithLAVA,Docker,andaFRDM-K64F:-DevelopmentSetup

But arguably once our changes have been upstreamed we should be able to to just switch back to using the default setup.

It's a matter of fact that https://github.com/Linaro/lite-lava isn't maintained properly (last update Jul 25). Hopefully that's due to: a) indeed, our working directly with/on upstream; b) lack of interdependencies of work done by us; c) regular updates on upstream releases. We definitely can maintain Linaro/lite-lava "better" if needed, but first aim is to maintain lite-lava-docker-compose well ;-).

I am able to launch a job on cc3220sf_launchxl and cc1352r1_launchxl after the upgrade,

Thanks for confirming!

but not without running 'make clean'. Do you know of a way to upgrade without nuking the database (in case there are test results I care about)?

I don't. That would require deep enough knowledge of how both docker-compose works (e.g. what and how it updates on detecting changes to its source files) and tracking/understanding LAVA database evolution. So far, I didn't need that info. I also work from the assumption that the whole idea of using docker is ensuring reproducibility, and for that to actually work, from-scratch rebuilds should be practices frequently (I did ~ dozen "make clean"'s today, and have-dozen "make build" (which are more painful of course)).

We definitely should care about persistence of some test results, but my understanding is that those should be at https://lite.validation.linaro.org/ (Though that's of course a separate task, for example, I don't know if cc3220sf_launchxl, etc. are installed there at all.)

It dawned on me I am missing some proxy ...

Ack, thanks for confirming, I also confirm that downloading external URLs works for me.

[vanti]

We definitely should care about persistence of some test results, but my understanding is that those should be at https://lite.validation.linaro.org/ (Though that's of course a separate task, for example, I don't know if cc3220sf_launchxl, etc. are installed there at all.)

I asked from the perspective of a general LAVA user (I had thought LAVA is supposed to target non-Linaro users as well). If someone outside of Linaro tries to install and setup LAVA independently, it'd be very useful if there is an easy way to upgrade LAVA while preserving previous test results.

[pfalcon]

@vanti

I asked from the perspective of a general LAVA user (I had thought LAVA is supposed to target non-Linaro users as well). If someone outside of Linaro tries to install and setup LAVA independently, it'd be very useful if there is an easy way to upgrade LAVA while preserving previous test results.

Ah, sure, that's definitely supported, and that's how upgrades are handled on https://validation.linaro.org/ , https://lite.validation.linaro.org/ , etc. LAVA is just a Django (webapp framework) application, and supports standardized database migrations living in dirs like https://git.lavasoftware.org/lava/lava/tree/master/lava_results_app/migrations and accessible via Django management interface (python manage.py).

However, mapping that generic Django knowledge to this specific docker-based setup is a different matter. This setup is definitely simplified and constrained by Docker matters, and seems to be targeted more at quick development setup, rather than production one.

Hopefully, that answers it - if you guys for example would want to maintain a persistent setup at TI, that's definitely possible, just requires more digging and learning "LAVA administration" craft.

[pfalcon]

Ok, thanks for reviews, merging.