On 29 June 2017 at 13:38, Li, Yifan2 <yifan2.li@intel.com> wrote:

Hostname is what I want, reason is that the project I am in wants LAVA control lxc and make lxc use SSH connect to device, also they implemented a runner contains SSH connection. So me as LAVA admin need to pass hostname to their runner script to connect to device, which I have my -2 on this and discussed/argued with other folks in this project several times. However I could not persuade them. L So I need to handle this issue and came here ask for your help.


Hostname is always the wrong choice here, it is just an arbitrary database label. The "hostname" of the device will be configured by the rootfs, not by the device configuration in LAVA. That is why each test job must specify the prompt string, which typically includes the username of the login and the hostname of the running system.

You need to use the target_mac support and set the MAC address of the primary NIC of the device then use that to make the connection - this is equivalent to what is done for ADB over IP. Alternatively, use target_ip and set a fixed IPv4 address for the device by configuring your DHCP server to always give the same IP address to the MAC of the NIC on that device. If you are using DNS for this, then it already needs to have a fixed IP address. There is usually no good reason to have a DUT listed in the DNS of the local network. It is not useful because the system deployed on that DUT changes with every test job, the device is usually powered off and any services provided over DNS by a DUT are temporary.

 

 

Thanks for your mail.

Yifan

 

From: Neil Williams [mailto:neil.williams@linaro.org]
Sent: Thursday, June 29, 2017 6:19 PM


To: Li, Yifan2 <yifan2.li@intel.com>
Cc: Lava-users@lists.linaro.org
Subject: Re: [Lava-users] Is it possible to get data in device dictionary inside a job?

 

 

 

On 29 June 2017 at 10:28, Li, Yifan2 <yifan2.li@intel.com> wrote:

Thanks Neil for such quick response!

 

The reason I am doing this is that I have some device-specific information and I need to pass this information to my test script. For example I have a device named demo-01 and the information maybe like “demo-production-123456” and I need to input that to my test script, which would be like: python test_runner.py –p demo-production-123456.

 

But why is this specific to the device and not to the test job? What exactly are you trying to achieve?

 

What is it about the device that means that the test_runner *cares* about the hardware instead of the software running on the device? Anything to do with the software is part of the test job submission (except possibly the firmware), so that should be handled by a test job submission parameter. e.g. the kernel build, the rootfs version. Other details can be retrieved from /sys or /proc on the running system. There should be very little that the test runner should need to know other than that.

 

Devices can be changed by admins at any time, the test must not rely on specific device information other than what is needed to access to device (which is why lava-target-mac exists, it allows AOSP tests to communicate with the device over IP using ADB). So information about a device within the test shell is limited to what the test shell might need to be able to communicate, e.g. network addresses.

 

If you are trying to relate the device hostname to the test shell results, then that is the wrong approach. The physical device can change without needing a change in the hostname.

 

Keep your tests portable - what matters is how the software performs on the device-type, not how one particular device compared with another device of the same device-type running the same software - *unless* one device is using SATA and one eMMC but that is handled by having device-tags. Device tags are then part of the test job submission which means that the test job submission can pass a parameter that matches the meaning of the device tag.

 

tag:

  - has_sata

 

parameters:

   - USING_SATA: 1

 

tag:

  - no_sata

 

parameters:

  - USING_SATA: 0

 

 

 

 

I am not sure where to save device information so I turned to add it into device dictionary of each device, but if there is a better way to do this, I would like to have a try. J I have read about ‘context’ in job submission but I found it is for modify properties in device dictionary.

 

Thanks for the documents about lava-target-mac and I will read your documents to see if I can came up with a good idea.

 

Thanks and Best Regards,

Yifan

 

From: Neil Williams [mailto:neil.williams@linaro.org]
Sent: Thursday, June 29, 2017 5:09 PM
To: Li, Yifan2 <yifan2.li@intel.com>
Cc: Lava-users@lists.linaro.org
Subject: Re: [Lava-users] Is it possible to get data in device dictionary inside a job?

 

On 29 June 2017 at 09:52, Li, Yifan2 <yifan2.li@intel.com> wrote:

Hello LAVA experts,

 

I am currently working with LAVA and was asked to find is there a way to get data from device dictionary inside a running job. Details like below:

I have a device name demo-01, and its device-dictionary have one line like “{% set my_property = ’my_prop’ %}”. Then I have a job running on demo-01 device, and I would like to use string ‘my_prop’ to passed into a script during running. Is it possible to get device-dictionary data directly from job definition(Job Submitter webpage) or test definition(yaml file)? If yes, how could I do this? If not, is there any good way you would like to share to solve this problem?

 

No, device configuration should generally not be available inside the test shell, it is admin-specific and a lot of the commands can often be inaccessible to the test shell or use scripts which only exist on the worker or be blocked by network configuration etc. There is no guarantee that a test shell running on a device will be able to contact the master, so direct retrieval is unlikely to work (plus you'd need a parser at the other end).

 

What is the property you are trying to set and retrieve and why? What does the test shell do with the value?

 

The test job submission itself support parameters and these are passed into the test shell. The most common example of that is the hacking session:

 

We do have support for exporting some values into the test shell overlay - lava-target-mac is one (we need some documentation of that but it has a fairly limited use case, so it's been largely internal until now).

 


 

--



 

--




--

Neil Williams
=============
neil.williams@linaro.org
http://www.linux.codehelp.co.uk/