On Mon, 28 Jan 2019 at 16:21, Dan Rue dan.rue@linaro.org wrote:
On Mon, Jan 28, 2019 at 09:24:26AM +0000, Milosz Wasilewski wrote:
On Fri, 25 Jan 2019 at 23:00, Dan Rue dan.rue@linaro.org wrote:
More updates! Described below, referenced links go to source:
- beaglebone-black is now working for me [1]
- ser2net containerized [2]
- LAVA upgrade process is documented [3]
- Squid container added; nginx images hack removed [4]
The beaglebone-black branch represents what's now an actual working docker-compose environment for my bbb, using a recent u-boot (this turned out to be the hardest part - totally unrelated to docker). I ended up running NFS and TFTP on the host and mounting the paths into the dispatcher. I'd like to containerize those still, but NFS is a bit difficult in particular and I just wanted to see things work.
The beaglebone-black branch is back to using the dispatcher without rebuilding it. I did this by breaking ser2net into its own container that can be found at danrue/ser2net and used as follows:
version: '3.4' services: ser2net: image: danrue/ser2net:3.5 volumes: - ./ser2net/ser2net.conf:/etc/ser2net.conf devices: - /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0The best part is running something like this to spy on the serial port during testing:
docker-compose exec dispatcher telnet ser2net 5001The LAVA upgrade has been documented in the README, but it's simple enough I'll reproduce it here:
1. Stop containers. 2. Back up pgsql from its docker volume sudo tar cvzf lava-server-pgdata-$(date +%Y%m%d).tgz /var/lib/docker/volumes/lava-server-pgdata 3. Change e.g. `lavasoftware/amd64-lava-server:2018.11` to `lavasoftware/amd64-lava-server:2019.01` andIs the content of /var/lib/lava-server/default/media/job-output/ also preserved in this scenario? If not, this dir should also probably be mapped into a volume so it is moved between migrated versions.
Oh, good catch. Fixed with a docker volume @ https://github.com/danrue/lava-docker-compose/blob/master/docker-compose.yml...
Today I managed to get LAVA and SQUAD working together in containerized setup. Here is the repository with docker-compose: https://github.com/mwasilew/lava-docker-compose I didn't update README yet. It's still not ideal as there might be race conditions starting SQUAD (only first time when DB is not yet populated). One big issue is lack of cmd line tools for user management in SQUAD. This means that admin user can be added but password can't be set. I'm planning to copy this code from LAVA to provide the same options. So far I managed to submit 1 QEMU job to LAVA via SQUAD proxy and retrieve the results once the job finished.
Comments are welcome :)
milosz
Hello Milosz,
I've been also playing with LAVA docker containers and docker-compose. I now provide a docker-compose.yaml file and some configuration files for lava-server at http://git.lavasoftware.org/lava/pkg/docker-compose/ This docker-compose files allows to run lava server services with each services running in is own container.
Hope that helps. Cheers
Le ven. 15 févr. 2019 à 18:54, Milosz Wasilewski < milosz.wasilewski@linaro.org> a écrit :
On Mon, 28 Jan 2019 at 16:21, Dan Rue dan.rue@linaro.org wrote:
On Mon, Jan 28, 2019 at 09:24:26AM +0000, Milosz Wasilewski wrote:
On Fri, 25 Jan 2019 at 23:00, Dan Rue dan.rue@linaro.org wrote:
More updates! Described below, referenced links go to source:
- beaglebone-black is now working for me [1]
- ser2net containerized [2]
- LAVA upgrade process is documented [3]
- Squid container added; nginx images hack removed [4]
The beaglebone-black branch represents what's now an actual working docker-compose environment for my bbb, using a recent u-boot (this turned out to be the hardest part - totally unrelated to docker). I ended up running NFS and TFTP on the host and mounting the paths into the dispatcher. I'd like to containerize those still, but NFS is a
bit
difficult in particular and I just wanted to see things work.
The beaglebone-black branch is back to using the dispatcher without rebuilding it. I did this by breaking ser2net into its own container that can be found at danrue/ser2net and used as follows:
version: '3.4' services: ser2net: image: danrue/ser2net:3.5 volumes: - ./ser2net/ser2net.conf:/etc/ser2net.conf devices: -/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
The best part is running something like this to spy on the serial
port during testing:
docker-compose exec dispatcher telnet ser2net 5001The LAVA upgrade has been documented in the README, but it's simple enough I'll reproduce it here:
1. Stop containers. 2. Back up pgsql from its docker volume sudo tar cvzf lava-server-pgdata-$(date +%Y%m%d).tgz/var/lib/docker/volumes/lava-server-pgdata
3. Change e.g. `lavasoftware/amd64-lava-server:2018.11` to `lavasoftware/amd64-lava-server:2019.01` andIs the content of /var/lib/lava-server/default/media/job-output/ also preserved in this scenario? If not, this dir should also probably be mapped into a volume so it is moved between migrated versions.
Oh, good catch. Fixed with a docker volume @
https://github.com/danrue/lava-docker-compose/blob/master/docker-compose.yml...
Today I managed to get LAVA and SQUAD working together in containerized setup. Here is the repository with docker-compose: https://github.com/mwasilew/lava-docker-compose I didn't update README yet. It's still not ideal as there might be race conditions starting SQUAD (only first time when DB is not yet populated). One big issue is lack of cmd line tools for user management in SQUAD. This means that admin user can be added but password can't be set. I'm planning to copy this code from LAVA to provide the same options. So far I managed to submit 1 QEMU job to LAVA via SQUAD proxy and retrieve the results once the job finished.
Comments are welcome :)
milosz
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
On Tue, 19 Feb 2019 at 10:10, Remi Duraffort remi.duraffort@linaro.org wrote:
Hello Milosz,
I've been also playing with LAVA docker containers and docker-compose. I now provide a docker-compose.yaml file and some configuration files for lava-server at http://git.lavasoftware.org/lava/pkg/docker-compose/ This docker-compose files allows to run lava server services with each services running in is own container.
what is the difference between lava-server and lava-master in your example? Also why apache2 container uses LAVA image not httpd image?
milosz
Hope that helps. Cheers
Le ven. 15 févr. 2019 à 18:54, Milosz Wasilewski milosz.wasilewski@linaro.org a écrit :
On Mon, 28 Jan 2019 at 16:21, Dan Rue dan.rue@linaro.org wrote:
On Mon, Jan 28, 2019 at 09:24:26AM +0000, Milosz Wasilewski wrote:
On Fri, 25 Jan 2019 at 23:00, Dan Rue dan.rue@linaro.org wrote:
More updates! Described below, referenced links go to source:
- beaglebone-black is now working for me [1]
- ser2net containerized [2]
- LAVA upgrade process is documented [3]
- Squid container added; nginx images hack removed [4]
The beaglebone-black branch represents what's now an actual working docker-compose environment for my bbb, using a recent u-boot (this turned out to be the hardest part - totally unrelated to docker). I ended up running NFS and TFTP on the host and mounting the paths into the dispatcher. I'd like to containerize those still, but NFS is a bit difficult in particular and I just wanted to see things work.
The beaglebone-black branch is back to using the dispatcher without rebuilding it. I did this by breaking ser2net into its own container that can be found at danrue/ser2net and used as follows:
version: '3.4' services: ser2net: image: danrue/ser2net:3.5 volumes: - ./ser2net/ser2net.conf:/etc/ser2net.conf devices: - /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0The best part is running something like this to spy on the serial port during testing:
docker-compose exec dispatcher telnet ser2net 5001The LAVA upgrade has been documented in the README, but it's simple enough I'll reproduce it here:
1. Stop containers. 2. Back up pgsql from its docker volume sudo tar cvzf lava-server-pgdata-$(date +%Y%m%d).tgz /var/lib/docker/volumes/lava-server-pgdata 3. Change e.g. `lavasoftware/amd64-lava-server:2018.11` to `lavasoftware/amd64-lava-server:2019.01` andIs the content of /var/lib/lava-server/default/media/job-output/ also preserved in this scenario? If not, this dir should also probably be mapped into a volume so it is moved between migrated versions.
Oh, good catch. Fixed with a docker volume @ https://github.com/danrue/lava-docker-compose/blob/master/docker-compose.yml...
Today I managed to get LAVA and SQUAD working together in containerized setup. Here is the repository with docker-compose: https://github.com/mwasilew/lava-docker-compose I didn't update README yet. It's still not ideal as there might be race conditions starting SQUAD (only first time when DB is not yet populated). One big issue is lack of cmd line tools for user management in SQUAD. This means that admin user can be added but password can't be set. I'm planning to copy this code from LAVA to provide the same options. So far I managed to submit 1 QEMU job to LAVA via SQUAD proxy and retrieve the results once the job finished.
Comments are welcome :)
milosz
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
-- Rémi Duraffort LAVA Team, Linaro
Hello Milosz,
Le dim. 24 févr. 2019 à 11:43, Milosz Wasilewski < milosz.wasilewski@linaro.org> a écrit :
On Tue, 19 Feb 2019 at 10:10, Remi Duraffort remi.duraffort@linaro.org wrote:
Hello Milosz,
I've been also playing with LAVA docker containers and docker-compose. I
now provide a docker-compose.yaml file and some configuration files for lava-server at http://git.lavasoftware.org/lava/pkg/docker-compose/
This docker-compose files allows to run lava server services with each
services running in is own container.
what is the difference between lava-server and lava-master in your example? Also why apache2 container uses LAVA image not httpd image?
lava-server is the gunicorn process serving the html pages lava-master is the scheduler and master process (master as in master <-> slave)
apache2 is serving static files (lava css, js, ...) that are coming from the lava-server image. Maybe there is a better way?
Cheers
On Mon, 25 Feb 2019 at 10:57, Remi Duraffort remi.duraffort@linaro.org wrote:
Hello Milosz,
Le dim. 24 févr. 2019 à 11:43, Milosz Wasilewski milosz.wasilewski@linaro.org a écrit :
On Tue, 19 Feb 2019 at 10:10, Remi Duraffort remi.duraffort@linaro.org wrote:
Hello Milosz,
I've been also playing with LAVA docker containers and docker-compose. I now provide a docker-compose.yaml file and some configuration files for lava-server at http://git.lavasoftware.org/lava/pkg/docker-compose/ This docker-compose files allows to run lava server services with each services running in is own container.
what is the difference between lava-server and lava-master in your example? Also why apache2 container uses LAVA image not httpd image?
lava-server is the gunicorn process serving the html pages lava-master is the scheduler and master process (master as in master <-> slave)
apache2 is serving static files (lava css, js, ...) that are coming from the lava-server image. Maybe there is a better way?
I have these 3 in single container. What is the benefit of separating gunicorn from lava-master? Did you possibly try to have several of gunicorn containers to balance the load? I'm not sure if it's (currently) possible to have more than one lava-master running.
milosz
Cheers
-- Rémi Duraffort LAVA Team, Linaro
Le lun. 25 févr. 2019 à 12:09, Milosz Wasilewski < milosz.wasilewski@linaro.org> a écrit :
On Mon, 25 Feb 2019 at 10:57, Remi Duraffort remi.duraffort@linaro.org wrote:
Hello Milosz,
Le dim. 24 févr. 2019 à 11:43, Milosz Wasilewski <
milosz.wasilewski@linaro.org> a écrit :
On Tue, 19 Feb 2019 at 10:10, Remi Duraffort remi.duraffort@linaro.org
wrote:
Hello Milosz,
I've been also playing with LAVA docker containers and
docker-compose. I now provide a docker-compose.yaml file and some configuration files for lava-server at http://git.lavasoftware.org/lava/pkg/docker-compose/
This docker-compose files allows to run lava server services with
each services running in is own container.
what is the difference between lava-server and lava-master in your example? Also why apache2 container uses LAVA image not httpd image?
lava-server is the gunicorn process serving the html pages lava-master is the scheduler and master process (master as in master <->
slave)
apache2 is serving static files (lava css, js, ...) that are coming from
the lava-server image. Maybe there is a better way?
I have these 3 in single container. What is the benefit of separating gunicorn from lava-master? Did you possibly try to have several of gunicorn containers to balance the load?
In this docker-compose setup, every service is running in his own container. The only benefits would be to have many gunicorn processes running in parallel for load balancing (and maybe HA). That's the next thing I wanted to evaluate.
I'm not sure if it's (currently) possible to have more than one lava-master running.
Currently, only one lava-master, lava-logs and lava-publisher can run in parallel. But we had evaluated the possibility to have many lava-logs running because that *might* be a bottleneck on some really large labs.
-
Milosz Wasilewski -
Remi Duraffort