On 8 June 2017 at 06:10, Arthur She <arthur.she@linaro.org> wrote:
> Thanks Neil.
>
> 2017-06-07 12:35 GMT-07:00 Neil Williams <neil.williams@linaro.org>:
>>
>> On 7 June 2017 at 18:21, Milosz Wasilewski <milosz.wasilewski@linaro.org>
>> wrote:
>> > On 7 June 2017 at 18:19, Neil Williams <neil.williams@linaro.org> wrote:
>> >> On 7 June 2017 at 18:12, Arthur She <arthur.she@linaro.org> wrote:
>> >>> Hi Neil,
>> >>> Thanks for your reply.
>> >>> I am trying to compose a test definition to run robot framework test.
>> >>> The test definition is not yet finished, I'd just want to have a test
>> >>> before
>> >>> I go further.
>> >>> It's something like Android CTS test, run the test in the host and the
>> >>> host
>> >>> will interact with the target, hikey, through network.
>>
>> Be very careful with terminology here. There is no host or target,
>> that leads to thinking of this as MultiNode. There is a device and
>> there is the dispatcher which happens to use an LXC to isolate
>> programs like fastboot.
>>
>> >> That needs a static IPv4 address to be assigned by the lab team.
>> >> Unless there is an adb command which can retrieve the IPv4 address of
>> >> the HiKey.
>> >
>> > This is not android test, so adb is out of the equation.
>>
>> OK, thanks Milosz.
>>
>> So to try and clear things up:
>>
>> 0: LAVA needs the LXC to use fastboot to deploy the files to the HiKey
>> - the same LXC can be used to run a test shell to use the network.
>
> Good
>>
>>
>> 1: The LXC is transparent to the HiKey and if programs in the LXC need
>> to talk to the HiKey over the network, MultiNode is not going to be
>> able to help because there is only one node involved - the HiKey.
>
> I see.
>>
>>
>> 2: If there was a tool which could talk to the HiKey over USB and
>> retrieve data, that could be used (which is how adb does it) but that
>> would need a similar tool / service running on the HiKey.
>
> We don't have such kind of tool in our Hikey OE image.
>>
>>
>> 3: In the absence of this tool, it is equivalent to trying to get the
>> dispatcher to communicate with the device over the network - the
>> device needs a fixed IPv4 address which can be set in the device
>> configuration so that the dispatcher / LXC can use it.
>
> If we set a static IP address for Hikey. Would it cause IP conflict?
> I mean will this static IP address conflicts with other devices in the LAB
> or when running the same test job for multiple times simultaneously ?

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.

Create the request on CTT as per the link given in the previous
message, included below.

>>
>>
>> 4. In your local tests, assume that this address can be obtained by
>> running a shell script (this would be how LAVA provides the
>> information).
>>
>> 5. Please be very clear about what operating system is being used on
>> the device in discussions about this method and that LXC is used for
>> the deployment stage. Avoid comparisons with CTS and AOSP test jobs.
>>
>> 6. Keep MultiNode for situations where there are two DUTs - remember
>> that the LXC needed to deploy files is actually part of the
>> dispatcher, not a device.
>>
>>
>> >>> Basically, what I need is 1. the IP address of the client 2. run some
>> >>> program in the client before the host starts the test in order to
>> >>> accept the
>> >>> commands from it.
>>
>> Please clarify here what you mean by host and client. Avoid thinking
>> of these as MultiNode. There is a DUT and there is an LXC acting as
>> the dispatcher. As each can run a POSIX shell, the terms need to be
>> consistent.
>>
>> >> Think of the LXC as a transparent container - it acts as the
>> >> dispatcher but has the ability to run arbitrary binaries like adb. In
>> >> the HiKey test job and in many others, the LXC is not a device, it is
>> >> the dispatcher itself.
>
> Thanks for the explanation. I think I got a feel for it.
>
>>
>> >>
>> >>> 3. before the host finished the test, the client shouldn't be released
>> >>> by
>> >>> LAVA. Which shouldn't be a problem, I think.
>>
>> Again, this hints of MultiNode - the LXC for a HiKey persists until
>> the test job itself completes. The device is powered off and the LXC
>> is destroyed - which happens first is irrelevant because nothing from
>> a test shell is allowed to happen between the two events. There is no
>> synchronisation to do here, no waiting for one or the other.
>>
>> >>> I am not sure if I have to use multi node test to accomplish it.
>> >>
>> >> No, it only uses LXC.
>> >>
>> >>> Chase gave me some CTS examples. However, I haven't had any ideas to
>> >>> get the
>> >>> client IP address with that approach.
>> >>
>> >> If you cannot obtain it with adb, it will have to be static and
>> >> assigned by the lab team. Open an issue in CT&T
>> >> https://projects.linaro.org/servicedesk/customer/portal/1
>>
>> That still applies.

Make a request for a number of HiKeys (not all) to have a fixed IPv4
address based on the MAC address of the network adaptor for the
purposes of your particular use case.

>>
>> >>
>> >>> Do you have any suggestions?
>> >>>
>> >>> Thanks a lot.
>> >>> Arthur
>> >>>
>> >>>
>> >>> 2017-06-06 23:59 GMT-07:00 Neil Williams <neil.williams@linaro.org>:
>> >>>>
>> >>>> On 7 June 2017 at 06:25, Arthur She <arthur.she@linaro.org> wrote:
>> >>>> > Hi,
>> >>>> > I am trying to run a multinode test job in LAVA v2.
>> >>>>
>> >>>> That doesn't look like a MultiNode test job. What are you trying to
>> >>>> achieve?
>> >>>>
>> >>>> LXC support does not require MultiNode but LXC can be used in a
>> >>>> MultiNode situation, should you require to have one test job
>> >>>> involving
>> >>>> a HiKey and another test job on mustang or panda or something and
>> >>>> then
>> >>>> synchronise the two devices.
>> >>>>
>> >>>> Neither of those links are MultiNode jobs. Make sure you are not
>> >>>> confusing the LXC protocol with MultiNode.
>> >>>>
>> >>>> The MultiNode protocol cannot be used to pass information from the
>> >>>> HiKey to the LXC which is managing the adb/fastboot calls to that
>> >>>> same
>> >>>> HiKey. Use adb to pull or push data to the device. (For non-AOSP
>> >>>> boots, use tools available within the LXC.)
>> >>>>
>> >>>> > It failed. 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?
>> >>>>
>> >>>> Yes.
>> >>>>
>> >>>>
>> >>>> https://git.linaro.org/lava-team/refactoring.git/tree/lxc-multinode.yaml
>> >>>>
>> >>>> However, it does not sound like you actually need MultiNode.
>> >>>>
>> >>>> What are you trying to do with the HiKey?
>> >>>>
>> >>>>
>> >>>> --
>> >>>>
>> >>>> Neil Williams
>> >>>> =============
>> >>>> neil.williams@linaro.org
>> >>>> http://www.linux.codehelp.co.uk/
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Neil Williams
>> >> =============
>> >> neil.williams@linaro.org
>> >> http://www.linux.codehelp.co.uk/
>> >> _______________________________________________
>> >> Lava-users mailing list
>> >> Lava-users@lists.linaro.org
>> >> https://lists.linaro.org/mailman/listinfo/lava-users
>>
>>
>>
>> --
>>
>> Neil Williams
>> =============
>> neil.williams@linaro.org
>> http://www.linux.codehelp.co.uk/
>
>



--

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