lava-users

lava-users@lists.lavasoftware.org

1 participants
950 discussions

Running MultiNode job on specific devices

by Frank, Matthias

Hello lava users, how can I run a multinode job on specific devices instead of (a possible set) of device_types? I plan to run CAN or RS485 communication tests which requires a wired connection between duts. Is is possible to submit a job to theses special duts or should is have device_types with only on device instance? Greetings, Matthias

7 years, 4 months

Deploying and maintaining a LAVA Lab

by Dave Pigott

Hi all, We’ve started a collaborate page on how to deploy and maintain devices and instances of LAVA Labs. https://collaborate.linaro.org/display/CTT/LAB+Device+Deployment+Guide <https://collaborate.linaro.org/display/CTT/LAB+Device+Deployment+Guide> Please understand that this is a work in progress. All suggestions for changes and additions are more than welcome. email lava-lab-team(a)linaro.org with questions and suggestions. Dave ---------------- Dave Pigott LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

7 years, 4 months

What happened if different worker link to different coordinator in one lava instance?

by cnspring2002

As title: What happened if different worker link to different coordinator in one lava instance for multinode job?

7 years, 4 months

query about lava usage for MCU like solution

by Hake Huang

Hi Sirs, Does LAVA support MCU like system? Which usually using a debugger to download image to a MCU internal flash, and get uart result? Regards, Hake

7 years, 4 months

jobs using notify with tokens, resubmit as different user

by Kevin Hilman

How can you have more than one LAVA user have the same token secret (e.g. for a notify callback.)? Example use case: - LAVA job with notify callbacks using token names - submited as user "bob", token names of "bob" map to actual token secrets - job fails - user "lab-admin" fixes some lab issues, re-submits job - job passes, but callbacks fail because tokens are associated with user "bob" Since the re-submitted job runs as user "lab-admin", the same token names and corresponding secrets don't exist. Naively, user "lab-admin" tries to copy the token secrets from user "bob" keeping the same token names, but this fails saying that "secret already exists". Why can't different users have the same secrets? I haven't looked at the code, but this limitation kind of suggests that the secret itself is the key in the db, which would prevent multiple secrets of the same. Kevin

7 years, 4 months

kexec boot mechanism

by Hemanth K V

Hello Lava-users, Do we have any sample reference yaml job definition which has booting the target with kexec method. Thanks, Hemanth.

7 years, 4 months

Build information in metadata

by Frank, Matthias

Hello lava users, I use in a test job linuximage, rootfs and dtb from file server location retrieved via http. These files are nightly build from Jenkins. The file links are static so I can use new images within the same test job definition. Jenkins generates also a build information text file with commit IDs an so on. How can I integrate the content of this file in the job metadata or job result log? Using metadata: build-readme: <link> in the job definition is not possible because the link is stable over different build, but the file content is changing. The DUT has no access to the file location because it is in an isolated network. Is there a way to cat the file content on the worker to metadata or job result? Greetings, Matthias

7 years, 4 months

Invalid device configuration

by Frank, Matthias

Hello lava users, my lava 2019.01 shows me a device with Health == Bad. The Transitions log give that message: March11, 3:02p.m. lava-health Good → Bad (Invalid device configuration) Where can I found information about a misconfigured device? The log files did not provide (in my eyes) sufficient information. As Health checks I use the smoke-tests. Kinds Regards, Matthias

7 years, 4 months

apt get install hang

by cnspring2002

I use lxc-mocker in docker container, everything is ok. Just if the package did not install in advance, then next command will hang in web: lxc-create -t ubuntu -n test_lava -- --release xenial --mirror http://mirror.bytemark.co.uk/debian --packages systemd,systemd-sysv --arch amd64 I enter the container, see: root@df67cf292479:/# ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 17:20 pts/0 00:00:00 /usr/bin/python3 /usr/bin/lava-slave --level DEBUG --log-file - --master tcp://192.168.1.10:5556 --socket-a root 8 0 0 17:20 pts/1 00:00:00 /bin/bash root 13 1 0 17:20 pts/0 00:00:00 lava-run [job: 837] root 19 13 0 17:20 pts/0 00:00:00 /bin/bash /usr/bin/lxc-create -q -t ubuntu -n test_lava -- --release xenial --mirror http://mirror.bytemark.c root 261 19 1 17:20 pts/0 00:00:00 apt-get -q install -y systemd systemd-sysv root 473 8 0 17:21 pts/1 00:00:00 ps -ef Seems "apt-get install" hang, but if I pre-install the systemd,etc, then everything will ok, the lxc-create will not hang. The same for lxc-attach mocker etc, all will hang if do "apt-get install" & no pakcage preinstall. Please suggest, thanks.

7 years, 5 months

docker-compose with lava

by Dan Rue

I started playing with the official lava images today and wanted to share my work in progress, in case others are doing something similar or have feedback. My goal is to deploy a lava lab locally. My architecture is a single host (for now) that will host both the lava server and one dispatcher. Once it's all working, I'll start deploying a qemu worker followed by some actual boards (hopefully). So far, I have the following docker-compose.yml: version: '3' services: database: image: postgres:9.6 environment: POSTGRES_USER: lavaserver POSTGRES_PASSWORD: mysecretpassword PGDATA: /var/lib/postgresql/data/pgdata volumes: - ${PWD}/pgdata:/var/lib/postgresql/data/pgdata server: image: lavasoftware/amd64-lava-server:2018.11 ports: - 80:80 volumes: - ${PWD}/etc/lava-server/settings.conf:/etc/lava-server/settings.conf - ${PWD}/etc/lava-server/instance.conf:/etc/lava-server/instance.conf depends_on: - database dispatcher: image: lavasoftware/amd64-lava-dispatcher:2018.11 environment: - "DISPATCHER_HOSTNAME=--hostname=dispatcher.lava.therub.org" - "LOGGER_URL=tcp://server:5555" - "MASTER_URL=tcp://server:5556" With that file, settings.conf, and instance.conf in place, I run 'mkdir pgdata; docker-compose up' and the 3 containers come up and start talking to each other. The only thing exposed to the outside world is lava-server's port 80 at the host's IP, which gives the lava homepage as expected. The first time they come up, the database isn't up fast enough (it has to initialize the first time) and lava-server fails to connect. If you cancel and run again it will connect the second time. A few things to note here. First, it doesn't seem like a persistent DB volume is possible with the existing lava-server container, because the DB is initialized at container build time rather than run-time, so there's not really a way to mount in a volume for the data. Anyway, postgres already solves this. In fact, I found their container documentation and entrypoint interface to be well done, so it may be a nice model to follow: https://hub.docker.com/_/postgres/ The server mostly works as listed above. I copied settings.conf and instance.conf out of the original container and into ./etc/lava-server/ and modified as needed. The dispatcher then runs and points to the server. It's notable that docker-compose by default sets up a docker network, allowing references to "database", "server", "dispatcher" to resolve within the containers. Once up, I ran the following to create my superuser: docker-compose exec server lava-server manage users add --staff --superuser --email dan.rue(a)linaro.org --passwd foo drue Now, for things I've run into and surprises: - When I used a local database, I could log in. With the database in a separate container, I can't. Not sure why yet. - I have the dreaded CSRF problem, which is unlikely to be related to docker, but the two vars in settings.conf didn't seem to help. (I'm terminating https outside of the container context, and then proxying into the container over http) - I was surprised there were no :latest containers published - I was surprised the containers were renamed to include the architecture name was in the container name. My understanding is that's the 'old' way to do it. The better way is to transparently detect arch using manifests. Again, see postgres/ as an example. - my pgdata/ directory gets chown'd when I run postgres container. I see the container has some support for running under a different uid, which I might try. - If the entrypoint of server supported some variables like LAVA_DB_PASSWORD, LAVA_DB_SERVER, SESSION_COOKIE_SECURE, etc, I wouldn't need to mount in things like instance.conf, settings.conf. I pushed my config used here to https://github.com/danrue/lava.home.therub.org. Git clone and then run 'docker-compose up' should just work. Anyway, thanks for the official images! They're a great start and will hopefully really simplify deploying lava. My next step is to debug some of the issues I mentioned above, and then start looking at dispatcher config (hopefully it's just a local volume mount). Dan

7 years, 5 months

← Newer
1
...
47
48
49
50
51
52
53
...
95
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users