On 14 June 2017 at 08:31, Li, Yongtao yongtao.li@hxt-semitech.com wrote:
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).
LAVA is not a booking system. Hosted devices have no place in the LAVA database.
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?
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.
All that already lives in the device template and/or device dictionary. There is no need for this in any database. It is configuration, not data.
Where you may need new tables, please use a separate program and a separate database. LAVA will continue to develop and mingling your database models into the LAVA models *will* cause failures at some later point.
Need to modify LAVA command line, add functions like lava-server reserve dut1, lava-server connect dut1.
No. LAVA has Offline device mode and that is all that should be used, if you need to have devices available via both methods.
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.
Simple answer is don't. When a device is taken offline in LAVA, you can use a separate program to handle "booking" the device for manual usage.
The tool will be developed based on https://github.com/Linaro/lava-server and will be installed on LAVA master, right?
No. I do not think it should be based on lava-server. The extra data needs to go into a separate model and a separate codebase.
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.
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 you mean VLANd?
https://validation.linaro.org/static/docs/v2/vland.html#vland-in-lava
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?
No, I don't think it will - not when you are trying to integrate this too closely into LAVA without being able to contribute this upstream.
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.
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users