Hello everybody,
I have some testcases which need a remote network connection to the DUT. I already managed to implement this using an LXC container as part of a multinode job.
Example: Check whether a telnet server is running on the DUT. Implementation: * DUT and LXC are deployed and booted as two roles in a multinode job * DUT sends its IP address to LXC via the multinode API (lava-send) and then waits for a signal (lava-wait) * LXC reads the IP address (lava-wait, lava_multi_node_cache.txt), tries a telnet connection to DUT (lava-test-case) and then sends a signal to DUT (lava-send) * DUT and LXC are shut down
Now I read that LXC containers can be used in a singlenode job context as well, using the "namespace" attribute. I tried this and got the LXC container running along with my DUT, without the need of a multinode job. However, the multinode API cannot be used in this case, obviously. Is there another possibility to submit the DUT's IP address to the LXC?
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@garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz
On 30 April 2018 at 13:47, Tim Jaacks tim.jaacks@garz-fricke.com wrote:
Hello everybody,
I have some testcases which need a remote network connection to the DUT. I already managed to implement this using an LXC container as part of a multinode job.
Example: Check whether a telnet server is running on the DUT. Implementation:
- DUT and LXC are deployed and booted as two roles in a multinode job
- DUT sends its IP address to LXC via the multinode API (lava-send) and
then waits for a signal (lava-wait)
- LXC reads the IP address (lava-wait, lava_multi_node_cache.txt), tries a
telnet connection to DUT (lava-test-case) and then sends a signal to DUT (lava-send)
- DUT and LXC are shut down
Now I read that LXC containers can be used in a singlenode job context as well, using the "namespace" attribute. I tried this and got the LXC container running along with my DUT, without the need of a multinode job. However, the multinode API cannot be used in this case, obviously. Is there another possibility to submit the DUT's IP address to the LXC?
Modify the DHCP configuration so that the DUT always gets the same IP address and then set that as device_ip - this will be available inside the test shell using https://git.linaro.org/lava/lava.git/tree/lava_dispatcher/lava_test_shell/la...
https://staging.validation.linaro.org/scheduler/device/staging-hi6220-hikey-...
Devices which have device_ip set then have a suitable device tag added (static_ip) and that allows test writers to get the right support.
On 30 April 2018 at 13:47, Tim Jaacks tim.jaacks@garz-fricke.com wrote: Hello everybody,
I have some testcases which need a remote network connection to the DUT. I already managed to implement this using an LXC container as part of a multinode job.
Example: Check whether a telnet server is running on the DUT. Implementation:
- DUT and LXC are deployed and booted as two roles in a multinode job
- DUT sends its IP address to LXC via the multinode API (lava-send) and then waits for a signal (lava-wait)
- LXC reads the IP address (lava-wait, lava_multi_node_cache.txt), tries a telnet connection to DUT (lava-test-case) and then sends a signal to DUT (lava-send)
- DUT and LXC are shut down
Now I read that LXC containers can be used in a singlenode job context as well, using the "namespace" attribute. I tried this and got the LXC container running along with my DUT, without the need of a multinode job. However, the multinode API cannot be used in this case, obviously. Is there another possibility to submit the DUT's IP address to the LXC?
Modify the DHCP configuration so that the DUT always gets the same IP address and then set that as device_ip - this will be available inside the test shell using https://git.linaro.org/lava/lava.git/tree/lava_dispatcher/lava_test_shell/la...
https://staging.validation.linaro.org/scheduler/device/staging-hi6220-hikey-...
Devices which have device_ip set then have a suitable device tag added (static_ip) and that allows test writers to get the right support.
Thanks for the hint, that should be possible.
But the general question would be of interest for me as well: Exchanging data between the LXC and the DUT via LAVA is not possible then, right?
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
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@garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz
On 30 April 2018 at 14:50, Tim Jaacks tim.jaacks@garz-fricke.com wrote:
On 30 April 2018 at 13:47, Tim Jaacks tim.jaacks@garz-fricke.com wrote: Hello everybody,
I have some testcases which need a remote network connection to the DUT.
I already managed to implement this using an LXC container as part of a multinode job.
Example: Check whether a telnet server is running on the DUT. Implementation:
- DUT and LXC are deployed and booted as two roles in a multinode job
- DUT sends its IP address to LXC via the multinode API (lava-send) and
then waits for a signal (lava-wait)
- LXC reads the IP address (lava-wait, lava_multi_node_cache.txt), tries
a telnet connection to DUT (lava-test-case) and then sends a signal to DUT (lava-send)
- DUT and LXC are shut down
Now I read that LXC containers can be used in a singlenode job context as
well, using the "namespace" attribute. I tried this and got the LXC container running along with my DUT, without the need of a multinode job. However, the multinode API cannot be used in this case, obviously. Is there another possibility to submit the DUT's IP address to the LXC?
Modify the DHCP configuration so that the DUT always gets the same IP
address and then set that as device_ip - this will be available inside the test shell using https://git.linaro.org/lava/ lava.git/tree/lava_dispatcher/lava_test_shell/lava-target-ip
staging-hi6220-hikey-r2-01/devicedict
Devices which have device_ip set then have a suitable device tag added
(static_ip) and that allows test writers to get the right support.
Thanks for the hint, that should be possible.
But the general question would be of interest for me as well: Exchanging data between the LXC and the DUT via LAVA is not possible then, right?
That depends on what can be done in the LXC to access the device - it's device and OS specific. AOSP test jobs use dedicated tools like fastboot and ADB to exchange files and commands to the DUT - however, the LXC remains in charge. Typically that requires udev support to add the relevant USB device to the LXC and may also require switchable USB hubs which is where things get expensive/complex.
To get files off the DUT, use the publishing artifacts support - that requires that the device has raised a network interface.
https://staging.validation.linaro.org/static/docs/v2/publishing-artifacts.ht...
On 30 April 2018 at 14:50, Tim Jaacks tim.jaacks@garz-fricke.com wrote:
On 30 April 2018 at 13:47, Tim Jaacks tim.jaacks@garz-fricke.com wrote: Hello everybody,
I have some testcases which need a remote network connection to the DUT. I already managed to implement this using an LXC container as part of a multinode job.
Example: Check whether a telnet server is running on the DUT. Implementation:
- DUT and LXC are deployed and booted as two roles in a multinode job
- DUT sends its IP address to LXC via the multinode API (lava-send) and then waits for a signal (lava-wait)
- LXC reads the IP address (lava-wait, lava_multi_node_cache.txt), tries a telnet connection to DUT (lava-test-case) and then sends a signal to DUT (lava-send)
- DUT and LXC are shut down
Now I read that LXC containers can be used in a singlenode job context as well, using the "namespace" attribute. I tried this and got the LXC container running along with my DUT, without the need of a multinode job. However, the multinode API cannot be used in this case, obviously. Is there another possibility to submit the DUT's IP address to the LXC?
Modify the DHCP configuration so that the DUT always gets the same IP address and then set that as device_ip - this will be available inside the test shell using https://git.linaro.org/lava/lava.git/tree/lava_dispatcher/lava_test_shell/la...
https://staging.validation.linaro.org/scheduler/device/staging-hi6220-hikey-...
Devices which have device_ip set then have a suitable device tag added (static_ip) and that allows test writers to get the right support.
Thanks for the hint, that should be possible.
But the general question would be of interest for me as well: Exchanging data between the LXC and the DUT via LAVA is not possible then, right?
That depends on what can be done in the LXC to access the device - it's device and OS specific. AOSP test jobs use dedicated tools like fastboot and ADB to exchange files and commands to the DUT - however, the LXC remains in charge. Typically that requires udev support to add the relevant USB device to the LXC and may also require switchable USB hubs which is where things get expensive/complex.
I see that. But as far as I understand that requires an additional physical connection between the LXC host and the DUT (which is USB in the Android case), doesn't it? If I want to use ADB over TCP, the device is still required to have a static IP address which has to be known to the LXC, right?
To get files off the DUT, use the publishing artifacts support - that requires that the device has raised a network interface.
https://staging.validation.linaro.org/static/docs/v2/publishing-artifacts.ht...
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
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@garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz
On 30 April 2018 at 15:32, Tim Jaacks tim.jaacks@garz-fricke.com wrote:
On 30 April 2018 at 14:50, Tim Jaacks tim.jaacks@garz-fricke.com wrote:
On 30 April 2018 at 13:47, Tim Jaacks tim.jaacks@garz-fricke.com
wrote:
Hello everybody,
I have some testcases which need a remote network connection to the DUT.
I already managed to implement this using an LXC container as part of a multinode job.
Example: Check whether a telnet server is running on the DUT. Implementation:
- DUT and LXC are deployed and booted as two roles in a multinode job
- DUT sends its IP address to LXC via the multinode API (lava-send) and
then waits for a signal (lava-wait)
- LXC reads the IP address (lava-wait, lava_multi_node_cache.txt), tries
a telnet connection to DUT (lava-test-case) and then sends a signal to DUT (lava-send)
- DUT and LXC are shut down
Now I read that LXC containers can be used in a singlenode job context
as well, using the "namespace" attribute. I tried this and got the LXC container running along with my DUT, without the need of a multinode job. However, the multinode API cannot be used in this case, obviously. Is there another possibility to submit the DUT's IP address to the LXC?
Modify the DHCP configuration so that the DUT always gets the same IP
address and then set that as device_ip - this will be available inside the test shell using https://git.linaro.org/lava/ lava.git/tree/lava_dispatcher/lava_test_shell/lava-target-ip
staging-hi6220-hikey-r2-01/devicedict
Devices which have device_ip set then have a suitable device tag added
(static_ip) and that allows test writers to get the right support.
Thanks for the hint, that should be possible.
But the general question would be of interest for me as well: Exchanging
data between the LXC and the DUT via LAVA is not possible then, right?
That depends on what can be done in the LXC to access the device - it's
device and OS specific. AOSP test jobs use dedicated tools like fastboot and ADB to exchange files and commands to the DUT - however, the LXC remains in charge. Typically that requires udev support to add the relevant USB device to the LXC and may also require switchable USB hubs which is where things get expensive/complex.
I see that. But as far as I understand that requires an additional physical connection between the LXC host and the DUT (which is USB in the Android case), doesn't it? If I want to use ADB over TCP, the device is still required to have a static IP address which has to be known to the LXC, right?
There is no implicit connection between the LXC and the DUT. *Anything* that happens inside the LXC must be explicitly configured. For USB that means udev. For ethernet, that means static IP.
To get files off the DUT, use the publishing artifacts support - that
requires that the device has raised a network interface.
publishing-artifacts.html
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
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@garz-fricke.com www.garz-fricke.com SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg Registergericht: Amtsgericht Hamburg, HRB 60514 Geschäftsführer: Matthias Fricke, Manfred Garz
Lava-users mailing list Lava-users@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lava-users
Hi Tim,
On Monday 30 April 2018 06:17 PM, Tim Jaacks wrote:
Now I read that LXC containers can be used in a singlenode job context as well, using the "namespace" attribute. I tried this and got the LXC container running along with my DUT, without the need of a multinode job. However, the multinode API cannot be used in this case, obviously. Is there another possibility to submit the DUT's IP address to the LXC?
This job https://validation.linaro.org/scheduler/job/1746124 demonstrates how to get the IP address of the DUT from within the LXC test definition using lava-target-ip command. But, in order to get this, the DUT must have a fixed IP address that should be defined in the device configuration as seen here - https://git-us.linaro.org/lava/lava-lab.git/tree/validation.linaro.org/maste...
Hope assigning a fixed IP by binding to the mac address shouldn't be a hard thing to do within a network.
The documentation for device_ip can be found here - https://staging.validation.linaro.org/static/docs/v2/lava-scheduler-device-d...
Thank You.
-
Neil Williams -
Senthil Kumaran S -
Tim Jaacks