lava-users May 2019

lava-users@lists.lavasoftware.org

18 participants
20 discussions

External worker devices in LXC / connection to DUTs

by Tim Jaacks

Hello, we are trying to add external interfaces on the worker to connect with the DUTs, for example a 4-port USB-to-RS232 converter. Our DUTs have multiple RS232 ports which shall be tested using this remote interface. We have already figured out how to integrate this hardware into the LAVA environment, so that it can be used within the LAVA LXC (using static_info in the device dictionary, resulting in the four /dev/ttyUSB* devices being visible there). First question: We need multiple of these converters attached to the worker. How do we integrate these into LAVA? They all have the same board_id, vendor_id and product_id. If I specify the board_id in the device dictionary multiple times, the device is still added only once. Second question: We need a way to specify to which of the /dev/ttyUSB* ports a certain RS232 port of the DUT is connected. The place where I would assume to put such information is the device dictionary. But how can we access this information within a LAVA test shell? The documentation specifies some similar mechanism for energy probes: https://validation.linaro.org/static/docs/v2/admin-lxc-deploy.html?highligh… It says "Devices which are not directly attached to the worker can also be supported, for example energy probes which communicate over the network". As far as I can tell from the code, though, this seems to be a hard-coded feature without any possibility of adding other custom hardware. Is that correct? If yes, why isn't there a generic mechanism to supply static_info from the device dictionary in the LAVA test shell? Or is there? How can we implement our scenario described above using LAVA? 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

4 years, 9 months

query to retrieve Lava errors

by Denis HUMEAU

After getting stats on my setup robustness, the step forward is have a complete view on the lava errors we meet in incomplete jobs. >From what I see in incomplete jobs, my intention is to query on test suite lava and the name "job". In the query builder, if I use test suite as condition model, I can't use the job field name. Do you have any advice on how to proceed? Denis

4 years, 10 months

lava-test-case only handles lower case results strings

by Patryk Mungai Ndungu

Hello, I have recently upgraded from 2018.11 to 2019.03 and have noticed that the results of a lot of the tests I have been running no longer got parsed correctly by LAVA. This was because I was sending the results using upper case results strings. Eg. lava-test-case <test-case> PASS opposed to lava-test-case <test-case> pass This resulted in the following logs in the lava job: Received signal: <TESTCASE> TEST_CASE_ID=ETH_T_001 RESULT=PASS Bad test result: PASS Changing my results parsing script to only send lower case results strings fixed the issue, but was this restriction intended with the upgrade? Kind Regards, Patryk

4 years, 10 months

Error: "deploy stage is missing" in multinode job

by Axel Lebourhis

Hi all, I'm currently trying to make a multinode job for CTS on Android 9. During this job, I need to unlock uboot so I use the "interactive" test action. But when I add it to my job definition, I get an error message during the run : "Nothing to run. Maybe the 'deploy' stage is missing, otherwise this is a bug which should be reported." If I remove the test action with the "interactive" method, I won't get that error. Maybe I'm missing something but I don't get what it could be. You will find attached a test job example which leads to this error. Best regards, Axel

4 years, 10 months

timeouts for deploy vs http-download

by Kevin Hilman

Hello, I'm trying to customize the http-download timeout as documented[1], but I doesn't seem to work. The global deploy time always seems to win. Based on the doc, I did this, I added the following to my job[2] timeouts: actions: http-download: minutes: 15 However, in the job output, you can see that the http-download timeout value is set to 25 min (1500 sec) which is coming from the deploy action timeout. I got the same result when tryin to use timeouts: connections: What am I missing? Kevin [1] https://validation.linaro.org/static/docs/v2/timeouts.html?highlight=http_d… [2] https://lava.automotivelinux.org/scheduler/job/3270/definition#defline44 [3] https://lava.automotivelinux.org/scheduler/job/3270#action_1-1-1

4 years, 10 months

Re: [Lava-users] Why make the decision to limit job context in lava master?

by Larry Shen

Thanks, Remi, So, looking forward to your patch which allow admins to extend the white list with a variable in the settings. Regards, Larry From: Remi Duraffort <remi.duraffort(a)linaro.org> Sent: Thursday, May 23, 2019 3:59 PM To: Larry Shen <larry.shen(a)nxp.com> Cc: lava-users(a)lists.lavasoftware.org Subject: [EXT] Re: [Lava-users] Why make the decision to limit job context in lava master? Caution: EXT Email Hello Larry, 1. We mainly have 2 kinds of situations: a) Something like "uboot_ums_flash" which already in linaro lava tree. In the past, this can be overridden by job context. And I guess a lots of other variables which spread every corner of different jinja2 files. Huge I think, I really worried how lava can add so many keys in whitelist... Why do you have to update uboot_ums_flash in the job definition and not in the device dictionary? This sounds more like a device specific information instead of a job definition one. Anyway, having a long list of keys in the white list is not really a problem. This is only a python array, nothing more. b) Something which just used in device jinja2 to control some different command in different situations. I know linaro accept upstreams for device-type, I have no idea if private lab's device jinja2 also useful for other people. Contributions are welcome. A rule of thumb for device-type integration/templates is often: is the device available for purchase by someone outside your company? If yes, then it's a good idea to upstream it. If not, then it's more a case-by-case decision. 2. Sounds you guys will not rollback this commit because security issue. So two suggestions: Sorry no :( a) I don't know how this security issue could impact for an internal lab which not exposed to external internet. Anyway, if possible to add a configure to any settings to let admin to decide if we care this security issue? More details to come later on, but I don't think this is a good idea. b) If a) not easy to do or not accept, if possible this whitelist be stored in database or other persist file, so user can free to add his own keyword to whitelist, then even we will upgrade lava to later new version, we can still remain the keyword setting in the past, meanwhile user still can free to add any keyword to whitelist without upstream again and again for this hard coded whitelist, I don't think this make sense. I'm currently writing down a patch to allow admins to extend the white list with a variable in the settings. Please consider. BTW, as Tim Jaacks said in other thread: this limit not happen in multinode job, is it a bug, so next release we will also have this backdoor closed? I'm fixing this second issue in https://git.lavasoftware.org/lava/lava/merge_requests/547<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.lavas…> Thanks for reporting it. Rgds -- Rémi Duraffort LAVA Team, Linaro

4 years, 11 months

auto_login and minimal boot

by Diego Russo

Hello, In my job definition I have a minimal boot: https://staging.validation.linaro.org/static/docs/v2/actions-boot.html?high… Documentation says "auto-login and transfer_overlay are both supported for this method." But if I add auto_login the schema validation in the submit page will raise a warning: "Valid definition with warnings: extra keys not allowed @ data['actions']['boot']['minimal']" Of course if I take the auto_login out, the validation is green. If I leave the auto_login, it will be used. I think the validation needs to reflect what documentation says. 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.

4 years, 11 months

Re: [Lava-users] Why make the decision to limit job context in lava master?

by Larry Shen

Thanks, Remi, 1. We mainly have 2 kinds of situations: a) Something like "uboot_ums_flash" which already in linaro lava tree. In the past, this can be overridden by job context. And I guess a lots of other variables which spread every corner of different jinja2 files. Huge I think, I really worried how lava can add so many keys in whitelist... b) Something which just used in device jinja2 to control some different command in different situations. I know linaro accept upstreams for device-type, I have no idea if private lab's device jinja2 also useful for other people. 2. Sounds you guys will not rollback this commit because security issue. So two suggestions: a) I don't know how this security issue could impact for an internal lab which not exposed to external internet. Anyway, if possible to add a configure to any settings to let admin to decide if we care this security issue? b) If a) not easy to do or not accept, if possible this whitelist be stored in database or other persist file, so user can free to add his own keyword to whitelist, then even we will upgrade lava to later new version, we can still remain the keyword setting in the past, meanwhile user still can free to add any keyword to whitelist without upstream again and again for this hard coded whitelist, I don't think this make sense. Please consider. BTW, as Tim Jaacks said in other thread: this limit not happen in multinode job, is it a bug, so next release we will also have this backdoor closed? Regards, Larry -----Original Message----- From: Lava-users <lava-users-bounces(a)lists.lavasoftware.org> On Behalf Of lava-users-request(a)lists.lavasoftware.org Sent: Tuesday, May 21, 2019 11:13 PM To: lava-users(a)lists.lavasoftware.org Subject: [EXT] Lava-users Digest, Vol 9, Issue 19 Caution: EXT Email Send Lava-users mailing list submissions to lava-users(a)lists.lavasoftware.org To subscribe or unsubscribe via the World Wide Web, visit https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.lav… or, via email, send a message with subject or body 'help' to lava-users-request(a)lists.lavasoftware.org You can reach the person managing the list at lava-users-owner(a)lists.lavasoftware.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Lava-users digest..." Today's Topics: 1. Re: Why make the decision to limit job context in lava master? (Remi Duraffort) 2. Re: timeouts for deploy vs http-download (Remi Duraffort) 3. Re: Using transfer overlay (Pete Dyer) ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 May 2019 17:02:35 +0200 From: Remi Duraffort <remi.duraffort(a)linaro.org> To: lava-users <lava-users(a)lists.lavasoftware.org> Subject: Re: [Lava-users] Why make the decision to limit job context in lava master? Message-ID: <CANJfhHeXiuVi02dMfmzeQ5EjnP=SqDymDNoyfwDB2XNN8ckodg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hello, we had to enforce the content of the context dictionary in order to fix a security issue that we found recently. The full details of the security issue will be disclosed when a CVE is available. We know that this is annoying for many people so we tried to collect all the valid use cases before the previous release. Which variables are you setting in the context? Is the corresponding code upstreamed? Cheers Le lun. 20 mai 2019 à 10:49, cnspring2002 <cnspring2002(a)aliyun.com> a écrit : > +1, we also have same issue, had to pending new version deploy. > > Message: 1 > Date: Mon, 20 May 2019 05:39:40 +0000 > From: Larry Shen <larry.shen(a)nxp.com> > To: "lava-users(a)lists.lavasoftware.org" > <lava-users(a)lists.lavasoftware.org> > Subject: [Lava-users] Why make the decision to limit job context in > lava master? > Message-ID: > < > DBBPR04MB63291E1DC4F5F202DEDFE16699060(a)DBBPR04MB6329.eurprd04.prod.out > look.com > > > > Content-Type: text/plain; charset="utf-8" > > For 2019.04 version, we see next: > > Job context > ----------- > > > The schema validator is now checking the content of the `context` dictionary. Only the following keys are now allowed: > > > * `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`, > `guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`, > `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga` > > * `bootloader_prompt`, `console_device`, `extra_kernel_args`, > `extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`, > `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`, > `test_character_delay`, `tftp_mac_address` > > Jobs using keys that are not listed in this list will be rejected. > > > We usually set an customized context in job, and in device-type jinja2, use this context to just different value to set proper parameters. > After this limit, all things break! > > So, my question is: > > > lava could be designed to as a framework to give freedom to users to do their things as in the past, why we now enhance so many limits to users? > And additional, and workaround for my scenario? > > Regards, > Larry > > > > > _______________________________________________ > Lava-users mailing list > Lava-users(a)lists.lavasoftware.org > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.lavasoftware.org%2Fmailman%2Flistinfo%2Flava-users&data=02%7C01% > 7Clarry.shen%40nxp.com%7C2ebbb071596f41c8816208d6ddfee338%7C686ea1d3bc > 2b4c6fa92cd99c5c301635%7C0%7C0%7C636940484145033600&sdata=cpnWI8y6 > NzawoUy%2BOtunqchIyXsaHO0ryYzPyJf3Gw0%3D&reserved=0 -- Rémi Duraffort LAVA Team, Linaro

4 years, 11 months

Using transfer overlay

by Pete Dyer

Hello, I'm using transfer overlay to get a set of tests onto the target. However I want to untar it into /scratch instead of / because of storage requirements. This I can do quite easily. However the tests are going to try to run from / (e.g. /lava-10473/bin/lava-test-runner /lava-10473/1) Is there a way of running tests from /scratch/lava-10473.... ? Or a way of defining a command to run immediately after the transfer overlay that makes a link between /lava-10473 and /scratch/lava-10473 ? Thanks. 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.

4 years, 11 months

Re: [Lava-users] Why make the decision to limit job context in lava master?

by cnspring2002

+1, we also have same issue, had to pending new version deploy. Message: 1 Date: Mon, 20 May 2019 05:39:40 +0000 From: Larry Shen <larry.shen(a)nxp.com> To: "lava-users(a)lists.lavasoftware.org" <lava-users(a)lists.lavasoftware.org> Subject: [Lava-users] Why make the decision to limit job context in lava master? Message-ID: <DBBPR04MB63291E1DC4F5F202DEDFE16699060(a)DBBPR04MB6329.eurprd04.prod.outlook.com> Content-Type: text/plain; charset="utf-8" For 2019.04 version, we see next: Job context ----------- The schema validator is now checking the content of the `context` dictionary. Only the following keys are now allowed: * `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`, `guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`, `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga` * `bootloader_prompt`, `console_device`, `extra_kernel_args`, `extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`, `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`, `test_character_delay`, `tftp_mac_address` Jobs using keys that are not listed in this list will be rejected. We usually set an customized context in job, and in device-type jinja2, use this context to just different value to set proper parameters. After this limit, all things break! So, my question is: lava could be designed to as a framework to give freedom to users to do their things as in the past, why we now enhance so many limits to users? And additional, and workaround for my scenario? Regards, Larry

4 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users May 2019