lava-users

lava-users@lists.lavasoftware.org

3 participants
927 discussions

by Li, Yongtao

Hi All, We have a Lab and the DUTs in the Lab will be used for both automation testing(LAVA) and manual usage(development, debug, manual testing). And we will develop a tool for the manual usage, please find the basic requirements of the tool in the attachment. I list possible solutions about how to develop the lab tool and let the tool cooperate with LAVA on the same Lab hardwares. which one is better? could you give your suggestions? 1. Develop the lab tool based on LAVA framawork. Need to modify LAVA DB: add some new tables for network ports, port attribution, port connection, usage log, notes, also need to add columns to existing tables lava_scheduler_app_device. Need to modify LAVA command line, add functions like lava-server reserve dut1, lava-server connect dut1. Need to add new codes for the features which LAVA doesn't support, part of codes may be reused, I need to look into LAVA and check how to reuse them. The tool will be developed based on https://github.com/Linaro/lava-server and will be installed on LAVA master, right? Most probably we will maintain the codes change in local repository because it is difficult to upstream thousands of codes changes to linaro master repository. We need to merge the changes in master repository to local repository. 2. Develop the lab tool as a separated tool and use separated DB. There are two ways to avoid the DUT conflicts between the lab tool and LAVA: a) Lab tool DB maintain all DUTs, LAVA DB also maintain all DUTs, when a user want to do automation testing on one DUT, he need to reserve this DUT via lab tool in advance, then he can run automation testing on the specified DUT. b),Divide the DUTs to two groups, one group is for automation testing and it will be added to LAVA DB, the other one group is for manual usage and will be added to lab tool DB. Another question about how to link/unlink two network ports dynamically(see requirement#7 in attachment) in automation testing. I am not sure whether LAVA can support this feature later, the simple way is supporting it in test script: Do the link/unlink in test script: subprocess.Popen(["lab-tool","link","dut1.eth_1g_1","dut2.eth_1g_1"]) , and test script needs to get DUT name from LAVA in advance. Does this work? BR Yongtao This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

8 years

LAVA v2 multinode test with hikey

by Arthur She

Hi, I am trying to run a multinode test job <https://staging.validation.linaro.org/scheduler/job/175378/definition> in LAVA v2. It failed <https://staging.validation.linaro.org/scheduler/job/175378#L555>. After a short discussion with Chase, I realized if I want to run multinode test job I have to use "lava-multinode" protocol. However, I still need "lava-lxc" to deploy the test image for hikey. I am wondering if it is possible to use two protocols, lava-lxc for deployment test image and lava-multinode to run the test, in the same test job? If yes, could you please provide some examples? Thanks, Arthur

8 years

if i can add the device_tags by the cmdline ?

by Xu, Hongyu

Hi , I known can add the device_tags by the web , and if i can add the device_tags by the cmdline ? Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

8 years

deploy a x86 device

by Li, Xuelian

Hello，Neil： 1.Can you give me a deploy flow for a x86 device . 2．I want to use web UI submit job for one time N jobs. (N>10) How can I do it? Thanks. Amanda This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

8 years

Can be used multi database in the lava ?

by Xu, Hongyu

Hi all, Can be used multi database in the lava ? And is there any introduction to this ? Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

8 years

LAVA installation in jessie and jessie-backports

by Senthil Kumaran S

Hi, Someone with the nickname "Nurav" pinged in #linaro-lava IRC channel last week regarding installation problem to install lava in jessie using the jessie-backports repository. The person also diligently followed up with me to check what is wrong with his/her installation on private messages. I did find sometime to do the testing today. Since, I do not know any contact details of 'Nurav' I am writing my findings here, based on lava installation I did on fresh jessie containers, hopefully the person is available in this mailing list and will see this message. The fresh installation went fine with both jessie and also using jessie backports and LAVA production-repo. I ve put up the complete log of the installations I tried in the following files: * Fresh installation of lava from jessie-backports - http://people.linaro.org/~senthil.kumaran/logs/lava-jessie-bp-installation.… * Installing 2017.5 lava from jessie to jessie-backports to production-repo - http://people.linaro.org/~senthil.kumaran/logs/lava-jessie-bp-installation-… HTH. Thank You. -- Senthil Kumaran http://www.stylesen.org/ http://www.sasenthilkumaran.com/

8 years

[LAVA V2] how to submit job to one specified device

by wangbo

In LAVA V1, we can use `target: {device hostname}` to submit job to one specified device, but I find V2 does not support this. ------------------ Best Regards. Bo Wang

8 years, 1 month

Board @ Desk: LAVAv2 + KernelCI in a single VM to test a kernel in a board connected to your laptop

by Agustin Benito Bethencourt

Hi, warning: long mail CIP is a Linux Foundation[1] initiative to create a commodity Linux based platform for train railway control systems, power plants, etc which needs to be maintained for a very long time. In extreme cases, for 50 years. The first outcome is the CIP-kernel, based on 4.4 LTS and maintained for now by Ben Hutchings, a colleague of mine. This week, within the CIP (Civil Infrastructure Platform) project, we have published a VM where we have integrated LAVAv2 and KernelCI on Debian so any developer can test a specific kernel in a board attached to his/her laptop[2]. You have probably read in this mailing list some questions coming from some colleagues of mine from Codethink. Since the project is initially focused on the CIP kernel, it was natural to select LAVA and KernelCI as our default tools. We would like to see in the near future our CIP kernel as part of kernelci.org We move slowly though since CIP is still a young project with very limited resources but for now, and due to the very unique requirements CIP needs to address[3], safety critical requirements among them, we need to get absolute control of the testing infrastructure/service we will use. As a previous step towards building our own testing/reporting infrastructure and service, understanding LAVAv2 and promoting it among the developers involved in this initiative is essential. I think that B@D will be useful for this purpose, allowing us to start testing and sharing the results among CIP devs. Codethink has invested a significant amount of effort in creating a step by step deployment-configure-test guide[4]. Any feedback is welcome. B@D is meant to significantly reduce the entry level effort to use both, LAVA and KernelCI. We consider B@D as a downstream project of LAVAv2 and KernelCI. Hopefully, once we start using it within CIP we will be able to provide meaningful feedback on this list. The team behind B@D, is subscribed to this list and the #linaro-lava IRC channel. We have our own mailing list cip-dev for general support of CIP related topics, so B@D too, but our idea is to route users here for LAVA specific questions that are unrelated with the set up of the environment and participate in supporting them up to the the best of our knowledge, if you think that is a good idea. We are unsure yet about the level of success we will get with this effort though. Since probably for many of you this is the first news you get about CIP and B@D, feel free to ask me or my colleagues. We will do our best to answer your questions. You can get all the technical information about B@D at feature page[5]. Feel free to download it[6]. The integration scripts are located in gitlab.com under AGPLv3 license[7]. Our cip-dev mailing list is obviously an open one[8]. I would like to finish thanking the devs for the great work done in LAVA and to those of you who have helped the Codethink guys to get to this point. LAVAv2 and KernelCI are complicated beasts, hard to swallow without support, and at the same time, very useful. I guess that is part of the beauty. [1] https://www.cip-project.org/about [2] https://www.cip-project.org/news/2017/05/30/bd-v0-9-1 [3] https://wiki.linuxfoundation.org/_media/cip/osls2017_cip_v1_0.pdf [4] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboar… [5] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptestingboar… [6] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipdownload [7] https://gitlab.com/cip-project/cip-testing/board-at-desk-single-dev [8] https://lists.cip-project.org/mailman/listinfo/cip-dev Best Regards -- Agustin Benito Bethencourt Principal Consultant - FOSS at Codethink agustin.benito(a)codethink.co.uk

8 years, 1 month

File permissions in /etc/lava-server

by Guillaume Tucker

Hi, I've hit an issue after upgrading LAVA on Debian Stretch from 2017.5-6486.59742fe-1 to 2017.5-6509.d71f267-1, trying to add or update device dictionaries using the "lava-tool device-dictionary" command then always failed. Between these two revisions, the following change was introduced: commit ae4d4776ca7b7454f5406159226e3c9327dd207f Author: Rémi Duraffort <remi.duraffort(a)linaro.org> Date: Tue May 2 15:22:33 2017 +0200 LAVA-757 Move device dictionaries to file system The device dictionaries are now saved in: /etc/lava-server/dispatcher-config/devices which was previously installed with the root user. The LAVA server instance is running under the "lavaserver" user, which didn't have write access to this directory. So I had to manually change the permissions, and then it all worked. Could you please add a step in the Debian package installation to change the permissions and ownership of the files in /etc/lava-server/ to fix this issue? Note: It may also be a good idea to propagate the IOError into the xmlrpclib.Fault error message rather than replacing it with a rather mysterious "Unable to store the configuration for %s on disk". I had to do this to find out the root cause of the error; I can send a patch, let me know. Best wishes, Guillaume

8 years, 1 month

Overridding lava_test_{results_,}dir

by Sjoerd Simons

Hey all, I'm currently hitting an interesting issue; We're deploying debian- based images in our tests which have most of / mounted read-only. Unfortunately the default deployment data for Debian indicates that the various lava-test-shell related directories show live in /lava-xxxxx to which in our booted image ofcourse nothing can write. It would be good to give test writers the freedom to specify a sensible base-path for lava's usage to avoid these types of issues. The option to add a Debian variant to deployment data on our setup is somewhat less attractive as that requires server configuration. (Changing the images to mount / as read-write is not an option as that would defeat the point of the test). -- Sjoerd Simons Collabora Ltd.

8 years, 1 month

← Newer
1
...
82
83
84
85
86
87
88
...
93
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users