Hi!
I'm trying to implement new method to lava. As a reference I took fastboot.
Now I can job with my new implemented method.
I want to work with lxc container as with fastboot. But same job as for fastboot with lxc, doesn't create lxc container and miss step with image validation.
Only start methods which are described in /lava_dispatcher/actions/deploy/qdl.py
What I miss?
Kind regards,
Ilya
Hi Team,
I have tried to run the QEMU related jobs for arm64 with the below
configurations , throwing an error.
Can you please let me know the what was the Infrastructure missing on this
job.
Thanks & Regards,
Dhanunjaya. P
Hi,
I'm trying to change the way LAVA searches for and passes USB devices
to LXC containers. Current code depends on arbitrary variables present
in the static_info dictionary that is part of the device dictionary.
This seems to be a problem for some users [1]. So the proposal was
made to get rid of the arbitrary variables entirely and use udev
variables (starting with ID_). The change was pretty simple to
implement but when I started changing the docs I realized there were
other classes of devices supported with static_info. Docs list ACME
Cape that can be connected over LAN [2]. I'm not aware of any users of
this code but I don't want to break the feature if there is anyone
using it. So if you're users of LAVA who connect ACME Cape using
static_info please reply to this thread. If I don't hear any replies I
will remove this support.
[1] https://git.lavasoftware.org/lava/lava/issues/335
[2] https://github.com/ARM-software/lisa/wiki/Energy-Meters-Requirements#user-c…
Best Regards,
milosz
What kind of command do you run to flash over usb?
Le jeu. 28 nov. 2019 à 13:26, dhanu msys <dhanuskd.palnati(a)gmail.com> a
écrit :
> Hi Remi,
>
> We were flashing through USB otg cable.
>
> USB deploy method supported by lava right?
>
> Regards,
> Dhanunjaya
>
> On Thu, Nov 28, 2019, 17:52 Remi Duraffort <remi.duraffort(a)linaro.org>
> wrote:
>
>> Hello,
>>
>> you should give more information if you want to have a proper answer.
>>
>> How do you flash the board? is it fully automatic?
>> Is this method already supported by LAVA?
>>
>>
>> Rgds
>>
>> Le jeu. 28 nov. 2019 à 07:48, dhanu msys <dhanuskd.palnati(a)gmail.com> a
>> écrit :
>>
>>> Hi Team,
>>>
>>> How can i deploy RTOS based Application Image on target.
>>>
>>> Notes :
>>> Target HW : STM32F429I-DISC1.
>>> RTOS : Open source RTOS
>>> Application Image (RTOS + Application specific code).
>>>
>>> We are able to flash the Developed Application Firmware (.out/.bin)
>>> through IAR IDE via USB, so we are in plan to make use of LAVA and run test
>>> applications automatically.
>>>
>>> So , Can you please provide some references to deploy this test
>>> scenarios in LAVA.
>>>
>>> Thanks & Regards,
>>> Dhanunjaya. P
>>> _______________________________________________
>>> Lava-users mailing list
>>> Lava-users(a)lists.lavasoftware.org
>>> https://lists.lavasoftware.org/mailman/listinfo/lava-users
>>
>>
>>
>> --
>> Rémi Duraffort
>> LAVA Architect
>> Linaro
>>
>
--
Rémi Duraffort
LAVA Architect
Linaro
Hello everyone,
Summary:
We would like to drop the support for stretch in the (near) future.
Details:
Currently lava-server and lava-dispatcher are supported on both debian
stretch and debian buster.
Since LAVA 2019.11, the lava-server and lava-dispatcher docker images are
based on debian buster and not stretch.
Unittest are still running on stretch, buster and bullseye but integration
tests (lavafed and meta-lava mainly) are using the docker container so they
run only on buster.
Dropping the support for stretch will:
* simplify testing
* allow to use more recent version of python and django
* remove some issues with old dependencies in stretch
But before dropping the support we need to ensure that users/admins had
some time to migrate to buster or to docker-based installations.
In an ideal world, I would drop the support for stretch on the 1st of
January 2020. But please answer to this mail so we can device of the right
date all together.
Thanks
--
Rémi Duraffort
LAVA Architect
Linaro
Hi, there,
We can set lava-test-shell timeouts in test job like next:
timeouts:
connections:
lava-test-shell:
minutes: 1
My question is: what's the suitable value for this?
Any performance consideration for this value, or in one word, what if I set it as small as possible?
Hi All,
I am experimenting with the interactive test action, but cannot get it to work reliably.
I tried to replicate what is documented here: https://docs.lavasoftware.org/lava/interactive.html#writing-tests-interacti…
I also took as example a job mentioned previously on this mailing list: https://validation.linaro.org/scheduler/job/1925569/definition
But If I come down to the simplest uboot test job (yaml + log attached), I still see false verdicts.
I first set 2 variables in uboot. Then I print them, and verify if the output contains the expected string.
Only the first case behaves as expected: "fail-expected-1".
All following tests go wrong:
Test case "fail-expected-2" fails, but for a wrong reason: "Matched a prompt (was expecting a success): '=> '"
And remaining test cases also show a wrong verdict because of this. Including the last 2 TCs which are supposed to pass, but are marked as failed.
I also tested in Linux and on a different platform, and the behavior is the same.
Am I missing something with the syntax? Or with serial console settings?
Thanks a lot for your help,
Philippe Mazet
