Hi Lava folks,
I am new to LAVA and trying to get some basic understand of lava. I am facing issues while I trying to set up a docker device in lava following the doc: https://lava.readthedocs.io/en/latest/admin/basic-tutorials/instance/instal…
Steps followed:
1. I have installed Debian VM on my mac book pro.
2. Installed lava: https://lava.readthedocs.io/en/latest/admin/basic-tutorials/instance/instal…
* Enabled lava site in apache “Production releases” https://docs.lavasoftware.org/lava/installing_on_debian.html (Btw, this step seems to be missing)
* Config like “ALLOW_HOSTS<https://docs.lavasoftware.org/lava/advanced-installation.html?highlight=all…>”, CSRF etc: (a
* Created one super user: https://lava.readthedocs.io/en/latest/admin/basic-tutorials/instance/config…
* Created a token (for lavacli): sudo lava-server manage tokens add --user root
1. Setup docker device for running tests: https://lava.readthedocs.io/en/latest/admin/basic-tutorials/device-setup/do… ( I am following command line using lava-cli)
* $LAVACLI device-types add docker
* $LAVACLI devices add --type docker --worker buster.localdomain docker01
* $LAVACLI devices dict set docker01 test.jinja2 (test.jinja2 contains {% extend "docker.jinja2" %} )
* $LAVACLI devices update --health UNKNOWN docker01
After step “3”, I have the following error: “Configuration Error: missing or invalid template.”
I am assuming there is some pre-condition I am not meeting for docker device. How can I get some more debug information on this? Can you help?
Cheers,
Saheer Babu
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hello, Milosz,
Another question:
I see your documentation suggest to use pdudaemon. But I had a look for you
validation lava lab:
https://validation.linaro.org/scheduler/device/hi6220-hikey-r2-02/devicedict,
I see you use /usr/local/lab-scripts/snmp_pdu_control
I want to know why your lab not use the one which you suggest? I had a look
for pdudaemon, found it won't wait there until PDU operation finish. Will
this have any issue? Will next logic start before the pdu really finish the
operation?
Hi,
We have a problem here needs your help, as it's critical to us, could you give some suggestion? Thanks in advance.
You know, we submit a MR here about reset shell: https://git.lavasoftware.org/lava/lava/-/merge_requests/1023
It's nearly compatible from 2018.11 to 2020.04 release when we patch it in local, the only changes I remember is once upon a time you changed all "internal_pipeline" to "pipeline", so we had to follow the new name.
But in yesterday's 2020.05 release, I saw this commit: https://git.lavasoftware.org/lava/lava/-/commit/eefeef1864cc055c48215169b61…
In this commit, the test action no longer been added as before like next:
def __init__(self, parent, parameters):
super().__init__(parent)
self.action = TestShellRetry()
self.action.job = self.job
self.action.section = self.action_type
parent.add_action(self.action, parameters)
It becomes next:
@classmethod
def action(cls, parameters):
return TestShellRetry()
Correspondingly, in parse.py, it becomes from next:
action(pipeline, parameters)
to next:
action = cls.action(parameters)
That means "parent pipeline" no longer been passed to next level pipeline, parse.py will responsible for low level action inject into pipeline.
Above change is the key issue we encountered as in our "ResetTestShell" we need to reuse the parameters of "Boot" in same namespace, we need it to operate UBoot & Login again after device reset, like next:
def __init__(self, parent, parameters):
super().__init__(parent)
boot_action_para = None
for per_action in parent.actions:
if per_action.parameters["namespace"] == parameters["namespace"]:
if per_action.__class__.__base__.__name__ == "BootAction":
boot_action_para = per_action.parameters
self.action = TestShellLoop(boot_action_para)
self.action.job = self.job
self.action.section = self.action_type
parent.add_action(self.action, parameters)
You see we could get the "Boot" action from its parent action, thus we could get the boot action's parameters defined in job.yaml, then reconstruct the boot action, inject it as a internal action to our own test action.
But now, we can't do it as parent action no longer be passed to low level action...
Could you give me some suggestion on it, if any other way I could get the parameters of boot action when I'm in test action?
Thanks again.
Regards,
Larry
Hi,
I am looking into https://git.lavasoftware.org/lava/pkg/docker-compose
I have few questions about it:
* Are there guidelines somewhere about how to administrate a "master only" instance run from this docker-compose? Like tutorials about creating/restoring a backup, periodic maintenance/cleanup, restart one of the containers idenpendantly, upgrade versions, etc...
* Is there an easy way to inject a backup created from a previous instance? (backup created with pg_dump. Note that I am not psql expert at all...)
* Is LAVA coordinator supported in this docker solution ?
Many thanks,
Philippe
Hi,
I am looking for the LTP test suite included(inbuild) rootfs.cpio file for
the Qualcomm Snapdragon (arm64) seris.
Please can some one let me know as where can I find this .cpio file in
Linaro's prebuild releases?
Regards,
Koti
Oh, the action indeed DOES cause an infrastructure error if it fails, my command simply did not return an error in case of a failure.
Sorry for the noise!
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Schlachthofstrasse 20
21079 Hamburg
Direct: +49 40 791 899 - 183
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
-----Ursprüngliche Nachricht-----
Von: Tim Jaacks
Gesendet: Donnerstag, 30. April 2020 16:32
An: lava-users(a)lists.lavasoftware.org
Betreff: Evaluating return value of user_commands
Hello everyone,
I am using a command action with pre-defined user_commands in the device dictionary for switching relays, as described here:
https://master.lavasoftware.org/static/docs/v2/actions-command.html
The return value does not seem to be evaluated, though. The test continues even if my user_command fails. I would assume that this causes an infrastructure failure, resulting in an incomplete job. Why is this not the case?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Schlachthofstrasse 20
21079 Hamburg
Direct: +49 40 791 899 - 183
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hello everyone,
I am using a command action with pre-defined user_commands in the device dictionary for switching relays, as described here:
https://master.lavasoftware.org/static/docs/v2/actions-command.html
The return value does not seem to be evaluated, though. The test continues even if my user_command fails. I would assume that this causes an infrastructure failure, resulting in an incomplete job. Why is this not the case?
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Schlachthofstrasse 20
21079 Hamburg
Direct: +49 40 791 899 - 183
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
WE MAKE IT YOURS!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz, Marc-Michael Braun
Hi team,
i am trying to login IRC channel for #linaro-lava.
https://webchat.freenode.net/#linaro-lava
But , There is no register option for new user. It takes me to the group as
Unregistered user. Please share the proper link to complete
the registration for #linaro-lava.
thanks
Regards
Nagendra S
Hi team,
I am new to lava-server. I have written and uploaded the job description
for QEMU-arm64 to boot. But I can see in logs both kerenl
Image-qemuarm64.bin and rootfs core-image-minimal-qemuarm64.ext4 files are
downloaded in /var/lib/lava/dispatcher/tmp/* directory.
But i am getting following error .
auto-login-action: Wait for prompt ['Linux version [0-9]'] (timeout
00:02:00)
*W: /etc/qemu-ifup: no bridge for guest interface foundqemu-system-aarch64:
-kernel
/var/lib/lava/dispatcher/tmp/27/deployimages-otsvre77/kernel/Image-qemuarm64.bin:
Could not open
'format=raw,file=/var/lib/lava/dispatcher/tmp/27/deployimages-otsvre77/rootfs/core-image-minimal-qemuarm64.ext4':
No such file or directoryConnection closed*
*Attaching .yaml file for job discription.* Please let me know if i miss
anything.
Note : LAVA-SERVER version:version: 2019.01-5
QEMU boot command:sudo qemu-system-aarch64 -kernel Image-qemuarm64.bin
-netdev tap,id=net0,ifname=tap1,script=no,downscript=no -device
virtio-net-device,netdev=net0 -machine virt -cpu cortex-a57 -drive
id=disk0,file=core-image-minimal-qemuarm64.ext4,if=none,format=raw -device
virtio-blk-device,drive=disk0 -no-reboot -nographic -m 512 --append
"root=/dev/vda rw console=ttyAMA0,38400 mem=512M highres=off ip=192.168.7.4:
:192.168.7.3:255.255.255.0 rootfstype=ext4 console=ttyS0"
Tested and working fine on my debian machine(with out lava server)
thanks
Regards
Nagendra S
