lava-users

lava-users@lists.lavasoftware.org

2 participants
918 discussions

Re: [Lava-users] LAVA master backup/restore

by Philippe Mazet (OSS)

Hi Rémi, I finally found this to work: For creating the backup, run backup command as postgres user, eg: docker exec --user postgres docker-compose_db_1 bash -c "pg_dump --username=lavaserver lavaserver > /var/lib/postgresql/data/lavaserver.sql" Then for restoring backup, place the sql file in a folder that will be mounted as a volume in postgres container, on /docker-entrypoint-initdb.d/. On way to do this is to create a dedicated docker-compose file (docker-compose-restore-backup.yaml) that will be appended to docker-compose.yaml: version: "3.4" services: db: volumes: - ./initdb.d:/docker-entrypoint-initdb.d Then: docker-compose stop docker container rm docker-compose_db_1; docker volume rm lava-server-pgdata docker-compose -f docker-compose.yaml -f docker-compose-restore-backup.yaml up -d I hope that helps. Philippe From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> On Behalf Of Remi Duraffort Sent: Friday, March 26, 2021 4:56 PM To: Philippe Mazet (OSS) <philippe.mazet(a)oss.nxp.com> Cc: lava-users(a)lists.lavasoftware.org <lava-users(a)lavasoftware.org> Subject: Re: [Lava-users] LAVA master backup/restore Hello Philippe, I haven't tried so I don't have the detailed procedure. When you find out, could you share the procedure ? Thanks Le mar. 23 mars 2021 à 11:28, Philippe Mazet (OSS) <philippe.mazet(a)oss.nxp.com> a écrit : Thanks Rémi, but result is the same when I start only the db container, even after a full cleanup (docker container rm docker-compose_db_1 && docker volume rm lava-server-pgdata): ERROR: database "lavaserver" already exists Seems to be related somehow to "POSTGRES_USER: lavaserver" in docker-compose.yaml. Reading the entrypoint script for postgres (https://github.com/docker-library/postgres/blob/master/docker-entrypoint.sh), I thought using PGUSER could help, but I didn't manage yet to get that working. I will continue digging into this... but if you have a detailed procedure somewhere, please share 😊 Thanks a lot! Philippe From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> On Behalf Of Remi Duraffort Sent: Monday, March 22, 2021 9:25 AM To: Philippe Mazet (OSS) <philippe.mazet(a)oss.nxp.com> Cc: lava-users(a)lists.lavasoftware.org <lava-users(a)lavasoftware.org> Subject: Re: [Lava-users] LAVA master backup/restore Le jeu. 18 mars 2021 à 16:22, Philippe Mazet (OSS) <philippe.mazet(a)oss.nxp.com> a écrit : Hi all, I am using the docker-compose solution to run a master: https://git.lavasoftware.org/lava/pkg/docker-compose I was wondering how to extract a backup of the DB, and re-inject it in a different instance. I found that postgres image has its own "restore" mechanism, based on initdb.d folder, as mentioned in the documentation: https://registry.hub.docker.com/_/postgres/ The entrypoint.sh script (https://github.com/docker-library/postgres/blob/master/docker-entrypoint.sh) handles the restore whenever the folder is /docker-entrypoint-initdb.d/ contains a .sql file. But when we store a backup in the container's /docker-entrypoint-initdb.d/ folder, and remove both the postgres image and its db-data volume, we get this error on next start: ERROR: database "lavaserver" already exists Full startup log attached. Questions: - Does Linaro's docker-compose solution modify postgres restore mechanism in any way? I guess that's only because lava will automatically create an empty lavaserver database. So in your use case, you should only start the db service and not any lava-* services. When the restoration has been done, you can restart every lava services. - How do you handle backup/restore at linaro? Thanks a lot in advance, Philippe Mazet NXP Semiconductors - Edge Processing Email: philippe.mazet(a)nxp.com _______________________________________________ Lava-users mailing list Lava-users(a)lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users -- Rémi Duraffort LAVA Architect Linaro -- Rémi Duraffort LAVA Architect Linaro

3 years, 11 months

Re: [Lava-users] Worker/master version mismatch

by Philippe Mazet (OSS)

I have submitted a MR to allow version mismatch: https://git.lavasoftware.org/lava/lava/-/merge_requests/1466 This feature is really a *must-have* for us. At our own risks of course. Thanks for considering it! We also have quite a few other MRs in the pipe. Some of them are few months old, even if all comments are replied. What is the appropriate way to get them reviewed/merged? ;-) Thanks a lot, Philippe From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> On Behalf Of Remi Duraffort Sent: Tuesday, January 26, 2021 10:04 AM To: Philippe Mazet (OSS) <philippe.mazet(a)oss.nxp.com> Cc: lava-users(a)lists.lavasoftware.org <lava-users(a)lavasoftware.org> Subject: Re: [Lava-users] Worker/master version mismatch Hello Philippe, I tried the lava-docker-worker but found it too restrictive, since we can’t customize the Docker container at all (adding some tools, cfg files, ssh keys, etc…), and was imposing usage of Docker within the job themselves (that would force us to rewrite many of our existing tests). That's an interesting use case. Maybe something that we might want to support. A possibility would be to specify the docker registry that you want to use instead of docker hub. As to “automatically run the right worker version”, I might have missed something. By checking lava-docker-worker sources, I concluded the Docker would simply refuse to start if version differs versus master. But do you mean it will automatically restart with the correct version when master is upgraded? That would be an easy fix (just adding a settings to lava_server and return depending on the setting value). But keep in mind that this might break at any release. Rgds -- Rémi Duraffort LAVA Architect Linaro

3 years, 11 months

We use “run_step” method in lava definitions, but it cannot work when we upgrade lava from 2018.11 stretch to 2021.01

by yangjianxiang

Hi ： We use “run_step” method in lava definitions, but it cannot work when we upgrade lava from 2018.11 stretch to 2021.01. How can we slove this problem. [cid:image001.png@01D73098.D3FE9C80]

3 years, 11 months

About device change permission.

by Larry Shen

Hi, guys, I'm currently debug permission issue on our production master, it looks like next: 1. I set user e.g. "zz" to group "imxcn", and assign device "imx8mm-evk-sh99" with the permission "change_device". But, in our production master, "zz"(not admin), can't change the device status. What's strange is: I have a local master on my hand, on this master, I do the same configure, the non-admin user can change the device status. 2. I check the database of our production master as next; auth_user: 39 | | 2021-03-30 08:37:32.98708+00 | f | zz auth_group: 8 | imxcn auth_user_groups: 290 | 39 | 8 lava_scheduler_app_groupdevicepermission: 91 | imx8mm-evk-sh99 | 8 | 9 92 | imx8mm-evk-sh99 | 8 | 5 auth_permission: 5 | Can submit jobs to device | 2 | submit_to_device 9 | Can change device | 2 | change_device django_content_type: 2 | lava_scheduler_app | device Looks all data is ok, so, base on above data, do you know any possible reason why our production server can't allow non-admin user change device permission? I'm a little lost as my local on hand server works, just central production server not work... Thanks.

3 years, 11 months

How to change device healthy using rest api?

by cnspring2002

Hello, LAVA maintainer: I used to use xmlrpc to change the status of our device, now I want to switch to rest api, but I don't know how to handle it with next: https://validation.linaro.org/static/docs/v2/data-export.html#v0-2 It didn't give an example, and also did not specify using GET, POST, PUT or DELETE, could you give an example to me? Like a curl command format. Thank you!

3 years, 11 months

Suggestion on avoiding cloning of same repositories multiple times.

by Kumar, Maanas

Hello, We have job definition with multiple test definitions as shown below. test: timeout: hours: 4 definitions: - repository: ssh://git@github.com:7999/<MytestRepo>.git from: git path: automated/linux/lttng/lttng.yaml name: lttng - repository: ssh://git@github.com:7999/<MytestRepo> from: git path: automated/linux/docker/docker.yaml name: docker We want to avoid multiple cloning of same repository as all our test-definitions are in one repo. We require suggestions on how to avoid cloning of same repository multiple times.? Regards, Maanas M D

3 years, 11 months

Re: [Lava-users] LAVA master backup/restore

by Philippe Mazet (OSS)

Thanks Rémi, but result is the same when I start only the db container, even after a full cleanup (docker container rm docker-compose_db_1 && docker volume rm lava-server-pgdata): ERROR: database "lavaserver" already exists Seems to be related somehow to "POSTGRES_USER: lavaserver" in docker-compose.yaml. Reading the entrypoint script for postgres (https://github.com/docker-library/postgres/blob/master/docker-entrypoint.sh), I thought using PGUSER could help, but I didn't manage yet to get that working. I will continue digging into this... but if you have a detailed procedure somewhere, please share 😊 Thanks a lot! Philippe From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> On Behalf Of Remi Duraffort Sent: Monday, March 22, 2021 9:25 AM To: Philippe Mazet (OSS) <philippe.mazet(a)oss.nxp.com> Cc: lava-users(a)lists.lavasoftware.org <lava-users(a)lavasoftware.org> Subject: Re: [Lava-users] LAVA master backup/restore Le jeu. 18 mars 2021 à 16:22, Philippe Mazet (OSS) <philippe.mazet(a)oss.nxp.com> a écrit : Hi all, I am using the docker-compose solution to run a master: https://git.lavasoftware.org/lava/pkg/docker-compose I was wondering how to extract a backup of the DB, and re-inject it in a different instance. I found that postgres image has its own "restore" mechanism, based on initdb.d folder, as mentioned in the documentation: https://registry.hub.docker.com/_/postgres/ The entrypoint.sh script (https://github.com/docker-library/postgres/blob/master/docker-entrypoint.sh) handles the restore whenever the folder is /docker-entrypoint-initdb.d/ contains a .sql file. But when we store a backup in the container's /docker-entrypoint-initdb.d/ folder, and remove both the postgres image and its db-data volume, we get this error on next start: ERROR: database "lavaserver" already exists Full startup log attached. Questions: - Does Linaro's docker-compose solution modify postgres restore mechanism in any way? I guess that's only because lava will automatically create an empty lavaserver database. So in your use case, you should only start the db service and not any lava-* services. When the restoration has been done, you can restart every lava services. - How do you handle backup/restore at linaro? Thanks a lot in advance, Philippe Mazet NXP Semiconductors - Edge Processing Email: philippe.mazet(a)nxp.com _______________________________________________ Lava-users mailing list Lava-users(a)lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users -- Rémi Duraffort LAVA Architect Linaro

3 years, 11 months

docker support for adb-fastboot

by Marcel Trattner

Dear LAVA-Users, as far as we know the lxc support for LAVA test is going to be depricated and docker should be used instead, so we tried to define a test job with docker. The lxc job for this device was completing but when we tried to follow this tutorial: https://www.youtube.com/watch?v=y-5DjzQztAk with the following test job: timeouts: job: minutes: 30 connection: minutes: 2 actions: finalize: seconds: 60 context: test_character_delay: 10 device_type: dragonboard_845_uSOM job_name: Docker-Test priority: 50 visibility: public metadata: build-url: '' actions: - deploy: to: fastboot docker: image: adb-fastboot timeout: minutes: 15 images: boot: url: https://path/to/image/boot.img reboot: hard-reset - boot: method: fastboot docker: image: adb-fastboot prompts: - root@(.*):/# timeout: minutes: 15 - test: docker: image: adb-fastboot timeout: minutes: 10 definitions: - repository: https://github.com/Linaro/test-definitions.git from: git path: automated/linux/android-platform-tools/install.yaml name: install-android-platform-tools-r2800 parameters: LINK: https://dl.google.com/android/repository/platform-tools_r28.0.0-linux.zip We got this error: [cid:image001.jpg@01D7224A.65849130] Are we doing something wrong or is this a bug? Regards, Marcel _____________________________________________________________________________________ Expleo Germany GmbH Sitz der Gesellschaft | Corporate Headquarters: M?nchen Handelsregister | Commercial Register: Amtsgericht M?nchen HRB 83252 Gesch?ftsf?hrung | Management: Ralph Gillessen, Marcus Ganguin This message contains information that may be privileged or confidential. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. _________________________________________________________ EMAIL LEGAL MENTION / DISCLAIMER This message contains information that may be privileged or confidential and is the property of the Expleo Services SAS, RCS Versailles 831 178 348, located, 3 avenue des Pr?s, 78180 Montigny Le Bretonneux - France. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. Ce message contient des informations qui peuvent ?tre privil?gi?es ou confidentielles et elles sont de la propri?t? d'Expleo Services SAS, RCS Versailles 831 178 348, situ?, 3 avenue des Pr?s, 78180 Montigny le Bretonneux-France. Il est destin? uniquement ? la personne ? qui est adress?. Si vous n'?tes pas le destinataire vis?, vous n'?tes pas autoris? ? lire, imprimer, conserver, copier, diffuser, distribuer ou utiliser ce message ou toute partie de celui-ci. Si vous recevez ce message par erreur, veuillez en avertir imm?diatement l'exp?diteur et supprimer toutes les copies de ce message.

3 years, 11 months

Re: [Lava-users] How many cts could be run parallel in one lava worker?

by Dave Pigott

Hi Larry, That is really underpowered for the sort of work you’re doing. We have a guideline of at least 8 cores and 16GB RAM. With only 4 cores you’re going to run into resource starvation issues. Thanks Dave ---------------- Dave Pigott LAVA Lab Lead Linaro Ltd t: (+44) (0) 1223 400063

3 years, 11 months

How many cts could be run parallel in one lava worker?

by Larry Shen

Hi, I'd like to know what's linaro's pc setup for android cts? I ask this question because in one of our pc, if run 3 cts together at the same time, after about 8 hours, some of job' log will hang at web. Check the server log, it looks the lava worker already sent the "END", while lava serer also sent the "END OK", also "description.yaml" received by server which means lava-run not crash. Just there is also one time's END resend, and the job/device still in running status for ever. Looks the zeromq connection to lava-log down? I'm not sure (We still link the device to 2020.08, not sure 2021.03 which don't use zmq helps or not). And, the dmesg keeps tell `docker0: port 3(vethb545eb3) entered disabled state`, so I suspect high resource usage in this pc when test cts may result in some connection issue. Our pc has 8G memory, Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 4 cores. What's your suggestion for pc configuration to run parallel cts jobs? Have your ever encountered similar issue? Thanks.

3 years, 11 months

← Newer
1
...
14
15
16
17
18
19
20
...
92
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users