...

1. 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 the ALLOWED_HOSTS line to add the ip or hostname of the machine.  In the example below, the ip 192.168.1.14 was added, you'll want to keep 127.0.0.1 and localhost .

   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" }

   
   

2. 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>

   
   

3. 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"] }

   
   

4. 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)

     
     

5. 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:

  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.

update-ca-certificates

...

As can be seen, lava-dispatcher and lava-ser2net containers didn't start up successfully. This usually can be rectified by running "docker-compose up". To bring up the system into a fully functional state, udev forwarder must be started manually too.

Related information

FRDM-K64F CMSIS DAPLink firmware versions

...

(Semi)Automated Containerized Setup

WARNING: The instructions in this section are WIP.

Setup instructions above provide a detailed walkthru on setting up and configuring containerized LAVA system. They are useful for initial acquaintance with this setup, but include quite a number of manual steps. That gets cumbersome and error-prone when the system needs to be setup multiple times. And one of the advantages of cointainer-based setup is easy tear-down/start-from-scratch cycle, allowing to perform full validation of changes, etc. easily.

To accommodate a faster (re)setup, we have a WIP Makefile targets which allow to make setup and configuration steps in semi-automated manner, considerably cutting on bootstrap time. These Makefile targets are intended to be treated as "executable documentation": you aren't suppose to run them blindly, but rather read/review them first to understand what exactly they do. This automated setup isn't intended to be one-click solution - instead, a small (~5) macro-steps are provided, utilizing Makefile's "multiple entry points" nature. This allows a user to control when these steps run, and most importantly, re-run to propagate updates - indeed, the frequency of various steps is different, as noted below. It also isn't supposed to be one-size-fits all solution - it's definitely open to further customization by individual users (actually, you need to customize it for your boards).

Workflow with the automated setup:

1. Start with plugging your board(s) into USB ports, and use "udevadm monitor -e | grep -i ID_SERIAL_SHORT" command to note their serial numbers. Each number should be put into files named devices/<lava_device_name>.serial. <lava_device_name> is the name of device which will be created on the LAVA side, and should in turn follow <device_type>-NN naming pattern. For example, for a (first) FRDM-K64F board, the file name is devices/frdm-k64f-01.serial
2. With all involved boards still connected to USB, run "make board-configs". This will create (or update) contrib/LAVA.rules, individual board jinja files, etc., as described in the "manual" section of this document. You will need to re-run "make board-configs" whenever you add/remove boards, or have serial numbers change.
3. make install - This will install files needed on the host, e.g. LAVA.rules and passthru script(s). Re-run when board set/properties (and thus LAVA.rules) changes.
4. make build - Build docker-compose images. Re-run if image contain is supposed to change.
5. make - Start up containerize LAVA setup. This also takes care of starting any host daemons (like udev forwarding daemon) too.
6. make lava-setup - Perform initial semi-automated LAVA configuration - run this once per LAVA setup, then can be run again to update configuration (see also sub-targets utilized by this target).
7. make stop - Stop LAVA setup (and any host-side daemons).
8. make clean - Tear down current LAVA setup, losing all data (use make followed by make lava-setup to start again).

Generally, these targets fall in 2 categories:

• board-configs, install, build - "host-side" setup, "run once", or whenever things outside specific LAVA container setup update.
• make, lava-setup, stop, clean - "container-side", use to managed lifecycle of current LAVA container.

Related information

FRDM-K64F CMSIS DAPLink firmware versions

Different FRDM-K64F boards in circulation have different CMSIS DAPLink firmware versions, which may affect board's use with LAVA (taking into account that there're different deployment methods - USB Mass Storage Device copying, pyocd, etc.) This section tries to enumerate versions seen, with notes on usage with LAVA. The version can be found via "DETAILS.TXT" file (or lack thereof) on board's emulated USB MSD device after plugging the board into host.

...

# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 0240000048824e45000b700bdd8900418761000097969900
HIC ID: 97969900
Auto Reset: 0
Automation allowed: 0
Overflow detection: 0
Daplink Mode: Interface
Interface Version: 0246
Git SHA: 0beabef8aa4b382809d79e98321ecf6a28936812
Local Mods: 0
USB Interfaces: MSD, CDC, HID
Interface CRC: 0x434eddd1
Remount count: 0

Useful link: MSD command documentation for 0246.

Adding multiple boards of the same type

In case you use the same board with a different debugger, or you just want to add a new board to your Lava-Docker setup you need to do the following steps:

1. Add a new physical board

This step assumes you have aleardy added the board's device type.

lavacli -i dispatcher devices add --type frdm-k64f --worker lava-dispatcher frdm-k64f-02

...

: 0beabef8aa4b382809d79e98321ecf6a28936812
Local Mods: 0
USB Interfaces: MSD, CDC, HID
Interface CRC: 0x434eddd1
Remount count: 0

Useful link: MSD command documentation for 0246.








Reset udev-forward script

Please stop udev-forward script (Ctr+C) and run the command:

...