...
Optional: Setup access for local IP/host
If you are running lava on a machine with a fixed IP (eg: a dedicated computer on your local network) you will want to modify the
overlays/lava-server/etc/lava-server/settings.conf
file to allow access. You'll want to modify theALLOWED_HOSTS
line to add the ip or hostname of the machine. In the example below, the ip192.168.1.14
was added, you'll want to keep127.0.0.1
andlocalhost
.Code Block language yml linenumbers true { "HTTPS_XML_RPC": false, "MOUNT_POINT": "/", "STATIC_URL": "/static/", "ALLOWED_HOSTS": ["192.168.1.14", "127.0.0.1", "localhost"], "CSRF_COOKIE_SECURE": false, "SESSION_COOKIE_SECURE": false, "EVENT_NOTIFICATION": true, "EVENT_TOPIC": "lava-server", "INTERNAL_EVENT_SOCKET": "tcp://lava-publisher:5557" }
- Optional: Add the proxy settings in lite-lava-dispatcher and ser2net images
It might be required to define proxy setting in lite-lava-dispatcher/Dockerfile and ser2net/Dockerfile
Code Block language bash ENV http_proxy=http://<user>:<pwd>@<proxy>:<port> ENV https_proxy=http://<user>:<pwd>@<proxy>:<port>
- Optional: Configure DNS in /etc/docker/daemon.json
Do this only if you are sure you need this. Otherwise, hardcoding a particular (local) DNS server may lead to issues when using another network connection, etc.
Get host DNS:
Code Block language bash nmcli dev show | grep 'IP4.DNS'
Set reported value in /etc/docker/daemon.json:
Code Block language yml { "dns": ["w.x.y.z"] }
Restart docker:
Code Block language yml sudo service docker restart
Run commands to build docker images and startup lava
Code Block language bash docker-compose build make
You'll see output of docker fetching and building the images, and then all LAVA containers starting up, followed by a fair amount of logging from LAVA itself as it starts up. This may take a few minutes to complete.
Here are some examples of the output one can expect during this phase:
Docker Compose/Build Phase
Code Block language bash galak@ubuntu:~/lite-lava-docker-compose$ make docker-compose up Creating volume "lava-server-pgdata" with default driver Creating volume "lava-server-devices" with default driver Creating volume "lava-server-health-checks" with default driver Creating volume "lava-server-joboutput" with default driver Pulling db (postgres:11.2-alpine)... 11.2-alpine: Pulling from library/postgres bdf0201b3a05: Pull complete 365f27dc05d7: Pull complete bf541d40dfbc: Pull complete 823ce70c3252: Extracting [========> ] 4.194MB/25.04MB a92a31ecd32a: Download complete 83cc8c6d8282: Download complete 7995b9edc9bf: Download complete 7616119153d9: Download complete b3f69561e369: Download complete
Lava containers being created
Code Block language bash Creating lava-server-db ... done Creating lava-dispatcher ... done Creating lava-ser2net ... done Creating lava-publisher ... done Creating lava-master ... done Creating lava-logs ... done Creating lava-server ... done Creating apache2 ...
Lava starting up
Code Block language bash lava-master | Applying lava_results_app.0012_namedtestattribute_metadata... OK lava-server | . lava-master | Applying lava_results_app.0013_buglinks... OK lava-master | Applying lava_results_app.0014_xaxis_maxlength_increase... OK lava-master | Applying dashboard_app.0002_auto_20140917_1935... OK lava-logs | . lava-master | Applying dashboard_app.0003_auto_20140926_1208... OK lava-master | Applying dashboard_app.0004_imagereportchart_is_delta... OK lava-dispatcher | 2019-05-09 19:01:08,522 DEBUG [BTSP] Checking master [lava-master:5556] to create socket for lava-dispatcher lava-dispatcher | 2019-05-09 19:01:08,524 DEBUG [BTSP] socket IPv4 address: 172.18.0.6 lava-dispatcher | 2019-05-09 19:01:08,525 INFO [BTSP] Greeting master => 'HELLO_RETRY' (using the same version?) lava-master | Applying dashboard_app.0005_imagereportchart_chart_height... OK lava-master | Applying dashboard_app.0006_auto_20141028_1146... OK lava-master | Applying dashboard_app.0007_imagereportchart_chart_visibility... OK lava-server | . lava-master | Applying dashboard_app.0008_imagechartfilter_is_all_tests_included... OK
Lava idle
Code Block language bash lava-dispatcher | 2019-05-09 19:03:21,510 DEBUG PING => master (last message 20s ago) lava-master | 2019-05-09 19:03:21,513 DEBUG lava-dispatcher => PING(20) lava-dispatcher | 2019-05-09 19:03:21,519 DEBUG master => PONG(20) lava-master | 2019-05-09 19:03:36,201 INFO scheduling health checks: lava-master | 2019-05-09 19:03:36,205 INFO scheduling jobs: lava-master | 2019-05-09 19:03:38,651 DEBUG lava-logs => PING(20) lava-logs | 2019-05-09 19:03:38,648 DEBUG PING => master lava-logs | 2019-05-09 19:03:38,657 DEBUG master => PONG(20) lava-master | 2019-05-09 19:03:41,549 DEBUG lava-dispatcher => PING(20) lava-dispatcher | 2019-05-09 19:03:41,546 DEBUG PING => master (last message 20s ago) lava-dispatcher | 2019-05-09 19:03:41,555 DEBUG master => PONG(20) lava-master | 2019-05-09 19:03:56,221 INFO scheduling health checks: lava-master | 2019-05-09 19:03:56,225 INFO scheduling jobs: lava-logs | 2019-05-09 19:03:58,681 DEBUG PING => master lava-master | 2019-05-09 19:03:58,684 DEBUG lava-logs => PING(20) lava-logs | 2019-05-09 19:03:58,690 DEBUG master => PONG(20) lava-master | 2019-05-09 19:04:01,579 DEBUG lava-dispatcher => PING(20) lava-dispatcher | 2019-05-09 19:04:01,577 DEBUG PING => master (last message 20s ago) lava-dispatcher | 2019-05-09 19:04:01,584 DEBUG master => PONG(20)
Verify lava is running
You can verify that lava has completed startup by trying to connect to the LAVA webserver in a web browser by going to localhost.
Here's what the startup webpage should look like in your web browser:
...
You then need to bind your host certificates to container by adding following line in lite-lava-docker-compose/docker-compose.yaml:
Code Block | ||
---|---|---|
| ||
lava-master: container_name: lava-master image: ${DC_SERVER_IMAGE} volumes: ... - /usr/local/share/ca-certificates:/usr/local/share/ca-certificates:ro |
Then, run the following command in the container and go back to job start step.
Code Block |
---|
update-ca-certificates |
...
Following the setup above will allow one to easily access both upstream tags/branches (master, or particular release), and LITE team's own branches, and switching between branches is often required to contribute back to LAVA.
Using repository above in docker build:
Manual way: Go thru docker-compose.yaml, search for "../lava", and uncomment corresponding sections.
What to uncomment: Almost all our work on LAVA should/would concentrate on "dispatcher" component. Thus 2 code paths (../lava/lava_dispatcher & ../lava/lava_common) should be uncommented for "lava-dispatcher" container. lava/lava_common actually contains metadata about dispatcher components (actions, etc.), which also should be known to lava-server. So, need to uncomment ../lava/lava_common for lava-server. These 3 replaced components should cover majority of work we're doing. Uncomment anything else only if you know what you're doing and sure you need to replace other LAVA components beyond just the dispatcher (in this case, you would likely need to thoroughly replace all components in all containers).
After uncommenting, you would need to teardown the previous container setup ("make clean") and bring up new to include your changes ("make", followed by "make lava-setup"). Of course, this will clear the database and results of previous jobs. The same procedure should be followed when switching branches in the "lava" repository.
Automathing dev setup: Manually uncommenting sections in docker-compose.yaml is cumbersome and error-prone. Instead, it's recommended to create a local branch in the lite-lava-docker-compose repo and capture these changes there, then rebase this branch when repo gets new changes. One of the possible branch setup for personal fork of lite-lava-docker-compose is:
- Create a personal fork of https://github.com/Linaro/lite-lava-docker-compose on github, e.g. https://github.com/pfalcon/lite-lava-docker-compose .
- In that fork, "master" belong to Linaro/lite-lava-docker-compose's upstream project (we never push anything there, but may pull from upstream from time to time).
- "lite" branch belongs to the LITE baseline setup. Each developer should be ready that it may be rebased on "master" occasionally.
- "<username>" is your personal branch, which captures configuration files for your boards, this allows to easily port your setup from machine to machine, and to track changes to it. E.g.: https://github.com/pfalcon/lite-lava-docker-compose/commits/pfalcon . You should rebase this branch onto "lite" regularly.
- "<username>-dev" is your personal branch for developmnet setup. It contains changes described in this section above, and should be rebased on branch "<username>" regularly. E.g.: https://github.com/pfalcon/lite-lava-docker-compose/commits/pfalcon-dev .
Related information
FRDM-K64F CMSIS DAPLink firmware versions
...