On 12 June 2017 at 00:39, Arthur She <arthur.she@linaro.org> wrote:
>
>
>> [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.
>
> So, how could the transparent LXC get the IP address of the DUT, hikey?

https://git.linaro.org/lava/lava-dispatcher.git/tree/lava_dispatcher/pipeline/lava_test_shell/lava-target-ip

Once the lab have configured the lab DHCP to always assign a
particular IPv4 address to the MAC address of the USB network adaptor
for a specific HiKey, that IPv4 address is added to the device
configuration of that HiKey by the lab team. The LAVA overlay for the
LXC then contains that information and the test writer calls
lava-target-ip to echo 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.
>
> I am confused. Please check the job file. In this test job, I allocated two
> devices, LXC and hikey.
> Hikey sent its IP address through multinode API, lava-send to LXC, and the
> LXC ping hikey successfully with that one.

So you now have two LXC's when only one is needed (once the LAB team
do their part). It will take slightly longer to run this test and it
suffers the same problems as the V1 test jobs using KVM because now a
dedicated LXC device has to be reserved alongside the HiKey.

The test job has two LXCs because one is explicitly in the MultiNode
group as a standalone device of the device-type LXC and another
transparent one is attached to the HiKey. You also have the complexity
of a MultiNode test job with the need to extract the IPv4 address from
the HiKey, transmit that through the MultiNode group and make the LXC
wait until that value is retrieved. With the static IPv4 address, the
one transparent LXC has access to that IPv4 address immediately and
there is one less LXC to manage.

Your arrangement will work well during testing but please file the
request to have a static IPv4 address for nominated HiKey devices so
that when this becomes part of a CI loop, we don't create more work
for the admins and more delays for test writers by using MultiNode
unnecessarily. (If this test job was to be submitted in batches, it
would quickly reserve all available LXC devices. That's manageable if
only one test job is doing things that way but it does not scale.)

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



--

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