On 9 June 2017 at 17:17, Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
On 9 June 2017 at 17:00, Arthur She arthur.she@linaro.org wrote:
Thanks Neil for your suggestion.
[cut]
It will be assigned from the MAC address of the network adaptor used by each HiKey, so as long as that does not change, the IP will not conflict. However, the lab team do want to minimise the number of fixed IP addresses used for devices, so this support may only be available on designed HiKeys and the test jobs would need to use device tags.
That means we have to hard code "device : IP address" mapping in somewhere. Either in the test job then pass it to the test definition or in the test definition itself. Because this test definition would be run in validation.l.o and staging.validation.l.o, I'd like to have it flexible enough. I copied the idea from your test job and submitted a multinode test job which pass client IP address through multinode API. It seems it is working fine. Would that be a good idea?
Arthur, I'm wondering why do you need to run the tests via ssh? Is this the same test we discussed at Connect (video capture with robotframework)? If so, the tests run entirely on the target. So there would be no need for the host part.
Take care when converting V1 testjobs to V2. V1 is full of host|client which is entirely down to the need for a full VM and MultiNode. V2 replaces the VM with LXC and drops MultiNode, so wherever the old job talked about host or client, that is irrelevant for the V2 job and will only confuse things.