lava-users

lava-users@lists.lavasoftware.org

4 participants
907 discussions

Loading LAVA specific kernel modules fails

by Tim Jaacks

Hello, the lava-dispatcher package installs a file in /etc/modules-load.d/lava-modules.conf, containing the following lines: install ipv6 modprobe ipv6 install brltty /bin/false On my debian 9.3 system, this file leads to failures when the systemd-modules-load service starts: Job for systemd-modules-load.service failed because the control process exited with error code. See "systemctl status systemd-modules-load.service" and "journalctl -xe" for details. The details in journalctl say: Jan 07 15:08:30 a048 systemd[1]: Starting Load Kernel Modules... -- Subject: Unit systemd-modules-load.service has begun start-up -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- Unit systemd-modules-load.service has begun starting up. Jan 07 15:08:30 a048 systemd-modules-load[2088]: Failed to find module 'install ipv6 modprobe ipv6' Jan 07 15:08:30 a048 systemd-modules-load[2088]: Failed to find module 'install brltty /bin/false' Jan 07 15:08:30 a048 systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE Jan 07 15:08:30 a048 systemd[1]: Failed to start Load Kernel Modules. Obviously the "install" syntax is supported only in /etc/modprobe.d: https://manpages.debian.org/stretch/kmod/modprobe.d.5.en.html But not in /etc/modules-load.d: https://manpages.debian.org/stretch/systemd/modules-load.d.5.en.html Is this a known issue? Mit freundlichen Grüßen / Best regards Tim Jaacks DEVELOPMENT ENGINEER Garz & Fricke GmbH Tempowerkring 2 21079 Hamburg Direct: +49 40 791 899 - 55 Fax: +49 40 791899 - 39 tim.jaacks(a)garz-fricke.com www.garz-fricke.com WE MAKE IT YOURS! Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun

5 years, 8 months

How to run off DUT tests?

by Diego Russo

Folks, We have the need to run some tests which requires a process off DUT to be executed. Examples are: * port scan like process against the DUT * cli tests which interact with the DUT The workflow could be like: * Deploy the DUT * Boot the DUT * Run a process off DUT (actual test) * Collect test results In our setup we assume there is always a network connection between the DUT and the LAVA dispatcher. How can we achieve such workflow with LAVA? Cheers -- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 8 months

Lavacli : configuration to get lava jobs logs

by Philippe BEGNIC

Dear all, I need to get "jobs logs" using lavacli. To do that, I use the following command : lavacli jobs logs <job_id> I can perform this operation with a user that has a profile "superuser". We have also users with restricted permissions ( they can only submit jobs using lavacli ), and I would like them to get logs using lavacli. So, I have consulted in the Lava django administration page, the users permission that can be set, but I could not find which option could allow a "basic user" to get log jobs using lavacli. Is it possible to allow a user with "basic profile" to do that ? If yes, with user permission have to be set ? Best regards Philippe Begnic

5 years, 8 months

zmq example not work

by cnspring2002

Just use the sample command "python zmq_client.py -j 357 --hostname tcp://127.0.0.1:5500 -t 1200" Get the error: Traceback (most recent call last): File "zmq_client_1.py", line 155, in <module> main() File "zmq_client_1.py", line 139, in main publisher = lookup_publisher(options.hostname, options.https) File "zmq_client_1.py", line 109, in lookup_publisher socket = server.scheduler.get_publisher_event_socket() File "/usr/lib/python3.5/xmlrpc/client.py", line 1092, in __call__ return self.__send(self.__name, args) File "/usr/lib/python3.5/xmlrpc/client.py", line 1432, in __request verbose=self.__verbose File "/usr/lib/python3.5/xmlrpc/client.py", line 1134, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib/python3.5/xmlrpc/client.py", line 1146, in single_request http_conn = self.send_request(host, handler, request_body, verbose) File "/usr/lib/python3.5/xmlrpc/client.py", line 1259, in send_request self.send_content(connection, request_body) File "/usr/lib/python3.5/xmlrpc/client.py", line 1289, in send_content connection.endheaders(request_body) File "/usr/lib/python3.5/http/client.py", line 1103, in endheaders self._send_output(message_body) File "/usr/lib/python3.5/http/client.py", line 934, in _send_output self.send(msg) File "/usr/lib/python3.5/http/client.py", line 877, in send self.connect() File "/usr/lib/python3.5/http/client.py", line 849, in connect (self.host,self.port), self.timeout, self.source_address) File "/usr/lib/python3.5/socket.py", line 694, in create_connection for res in getaddrinfo(host, port, 0, SOCK_STREAM): File "/usr/lib/python3.5/socket.py", line 733, in getaddrinfo for res in _socket.getaddrinfo(host, port, family, type, proto, flags): socket.gaierror: [Errno -2] Name or service not known I wonder for following code, why http://tcp://127.0.0.1:5500/RPC2 will finally be passed to ServerProxy? If I remove http, just tcp://127.0.0.1:5500/RPC2, it will say "OSError: unsupported XML-RPC protocol" If I remove tcp, just http://127.0.0.1:5500/RPC2, it will hang in get_publisher_event_socket I use 2018.11 version, please suggest!!! xmlrpc_url = "http://%s/RPC2" % (hostname) if https: xmlrpc_url = "https://%s/RPC2" % (hostname) server = xmlrpc.client.ServerProxy(xmlrpc_url) try: socket = server.scheduler.get_publisher_event_socket()

5 years, 8 months

How can I run lava-publisher service in docker container?

by tomato

I am trying to submit test job using squad. When squad fetch the result of lava, the interval is too long. It takes at least 1 hour. I want to reduce fetch time as short as possible. This is what Squad team answer. Alternatively you can turn on ZMQ notifications in LAVA and run squad listener. This will cause test results to be fetched immediately after the test job finishes in LAVA. Enabling ZMQ publisher: https://master.lavasoftware.org/static/docs/v2/advanced-installation.html#c…. SQUAD listener is a separate process. It doesn't need any additional settings on top of what you already have. So I want to try restart lava-publisher service. I am running lava-server and dispatcher using Linaro lava docker image. On docker container, there is no service named lava-publisher. How can I manage this? Thanks.

5 years, 8 months

Differentiate RPi3 B and B+ on LAVA

by Diego Russo

Hello, Our LAVA deployment has both RPi3 B and B+ and we are interested only on the 32bit version. The device type to use looks like: https://git.lavasoftware.org/lava/lava/blob/master/lava_scheduler_app/tests… Does this device type cover both B and B+? I mean, can we use it for B+ as well? If yes, what's the best way to differentiate those on LAVA? Creating a new device type for B+ (which is the same of the above) or using tags? Thanks -- Diego Russo | Staff Software Engineer | Mbed Linux OS ARM Ltd. CPC1, Capital Park, Cambridge Road, Fulbourn, CB21 5XE, United Kingdom http://www.diegor.co.uk - https://os.mbed.com/linux-os/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 8 months

Splitting the lava-server docker image

by Olli Vainola

Hi, I've been using the lava-server docker image (hub.lavasoftware.org/lava/lava/lava-server:2018.10) for a couple of weeks and I had some problems on making the data persistent for the postgres (mapping the volume from host to container). Anyways I decided to take postgres out from the startup by modifying the entrypoint.sh file: ++++++++++++++ Added these lines after start_lava_server_gunicorn -function ++++++++++++++++++++++++++ if [[ ! -z $DJANGO_POSTGRES_SERVER ]]; then txt="s/LAVA_DB_SERVER=\"localhost\"/LAVA_DB_SERVER=\"$DJANGO_POSTGRES_SERVER\"/g" sed -i $txt /etc/lava-server/instance.conf fi if [[ ! -z $DJANGO_POSTGRES_PORT ]]; then txt="s/LAVA_DB_PORT=\"5432\"/LAVA_DB_PORT=\"$DJANGO_POSTGRES_PORT\"/g" sed -i $txt /etc/lava-server/instance.conf fi ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ---------------------------- Commented out these lines ----------------------------- # Start all services #echo "Starting postgresql" #/etc/init.d/postgresql start #echo "done" #echo #echo "Waiting for postgresql" #wait_postgresql #echo "[done]" #echo -------------------------------------------- ---------------------------------------------------- After that I created a new Dockerfile and built a new image: +++++++++++++++++++++++++ Dockerfile +++++++++++++++++++++++ FROM hub.lavasoftware.org/lava/lava/lava-server:2018.10 COPY ./entrypoint.sh /root/ RUN chmod 755 /root/entrypoint.sh ENTRYPOINT ["/root/entrypoint.sh"] ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> sudo docker build -t lava-server:mod . Just to get all up and running I made a docker-compose.yml file to kick postgres and lava-server up +++++++++++++++++++++++++++ docker-compose.yml +++++++++++++++++++++++++ version: '3' services: postgres: image: postgres:11 restart: always environment: POSTGRES_DB: lavaserver POSTGRES_USER: lavaserver POSTGRES_PASSWORD: d3e5d13fa15f lava-server: depends_on: - postgres image: lava-server:mod environment: DJANGO_POSTGRES_PORT: 5432 DJANGO_POSTGRES_SERVER: postgres ports: - "80:80" +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I still feel that there is too much going on inside that lava-server:mod image, since it has following softwares running: * Lavamaster * Gunicorn * Logger * Publisher What do you think, should I still break it into smaller pieces? Pros on this would be that softwares wouldn't die silently (started by using '&' and docker could try to restart them), logs would be in their own logs windows' (docker log CONTAINER) and containers themselves would be more configurable via environment variables. Br Olli Väinölä IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 8 months

Re: [Lava-users] [Lava-announce] Regular LAVA team design discussions open to developers

by Milosz Wasilewski

On Wed, 16 Jan 2019 at 17:33, Steve McIntyre <steve.mcintyre(a)linaro.org> wrote: > > Hi, > > In founding the LAVA Software Community Project, the team planned to > open up LAVA development more. As already announced by Neil in > September, we have already moved our infrastructure to a GitLab > instance and LAVA developers and users can collaborate there. [1] > > The next step in our process is to also open our regular development > design meetings to interested developers. The LAVA design meeting is > where the team gets together to work out deep technical issues, and to > agree on future development goals and ideas. We run these as a weekly > video conference using Google Hangouts Meet [2], We now wish to > welcome other interested developers to join us there too, to help us > develop LAVA. Steve, the only missing bit is which day and what time? :) milosz > > Summaries of the meetings will be posted regularly to the lava-devel > mailing list [3], and we encourage interested people to subscribe and > discuss LAVA development there. > > [1] https://git.lavasoftware.org/ > [2] https://meet.google.com/qre-rgen-zwc > [3] https://lists.lavasoftware.org/mailman/listinfo/lava-devel > > Cheers, > -- > Steve McIntyre steve.mcintyre(a)linaro.org > <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs > _______________________________________________ > Lava-announce mailing list > Lava-announce(a)lists.lavasoftware.org > https://lists.lavasoftware.org/mailman/listinfo/lava-announce

5 years, 8 months

Change archive and media path

by Axel Lebourhis

Hi everyone, I want to change the default path of MEDIA_ROOT and ARCHIVE_ROOT. So in /etc/lava-server-settings.conf I wrote this : "MEDIA_ROOT": "/data/lava/var/lib/lava-server/default/media", "ARCHIVE_ROOT": "/data/lava/var/lib/lava-server/default/archive", This seems to work but the web UI doesn't display the job output and when I try to download the plain log, it returns an error saying it can't be found. Could you tell me what should I do to make the web ui find the job outputs ? Best regards, Axel

5 years, 8 months

Git authentication

by Pete Dyer

In the thread about Git Authentication a solution was proposed using git credentials and the fact that the dispatcher is running as root. See: https://lists.lavasoftware.org/pipermail/lava-users/2018-December/001455.ht… I've worked out that even though the dispatcher is running as root, the environment is purged based upon env.yaml that is sent over from the master. I found that I had to add HOME=/root into env.yaml on the master for the git clone to pick up the files in the /root folder. Hope this helps anyone else trying to do this. Pete IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 years, 8 months

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users