[cut]

> That means we have to hard code "device : IP address" mapping in somewhere.

No, not the test writer - the admins. It becomes part of the device
configuration and the test writer has no control over that value, the
test writer can simply obtain it.

> 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?

No. The LXC is not visible to MultiNode.

>>
>>
>> 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/
>
>



--

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