Hello,
Is there a way to overwrite the SERVER_IP variable either in the LAVA environment or in the device-types template/device dictionary? https://lava.ciplatform.org/static/docs/v2/migrating-admin-example.html?hig…
No matter what I do, it remains in the rendered yaml file for a device. Unfortunately, the IP it picks up for the environment I'm working is wrong, as I'm running LAVA within a docker-container and it picks up the IP of the container, but the tftp server (within docker) is proxified to the host, meaning that the IP address it needs to pick up is the host's IP. Hence my question, is there a way to overwrite it so that the desired IP appears in the rendered job submission yaml?
Thanks,
Patryk
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
Hello,
When trying to use lavacli to add a remote worker, it works fine if
the user is a superuser. However, if I drop the superuser privileges
and add just the privileges for adding workers, it fails with:
Unable to call 'workers.add': <Fault 403: "User 'testuser' is not superuser."
we even tried enabling all the permissions for that user, but leaving
the superuser flag off, and it still fails.
Why does this require superuser and the specific permissions related
to workers don't work?
Kevin
Hi,
I made a first attempt to add REST API for some LAVA objects (jobs,
devices and device types). The API is very rudimentary but already
solves some basic job filtering issues. However I'm not sure how to
add dependencies. There are 2 packages required for this code to work
properly. Pip packages are named 'djangorestframework' and
'djangorestframework-filters'. Former has a corresponding debian
package 'python3-djangorestframework' but the later does not. Any
hints how to add proper dependencies to LAVA?
The code can be found here:
https://git.lavasoftware.org/mwasilew/lava/tree/rest_api
milosz
Hello,
I am looking for a suitable method for the following use-case: during test,
I need to access the connection to the workstation that runs my LAVA worker
and use it as a second namespace in order to be able to issue some commands
on the the workstation (like playing an audio file). In other words I need
to integrate the workstation as an auxiliary device needed for testing in
the test job definition (like ssh <user>@<ws_ip_addr> and send some
commands). Using LXC is not an option at this moment.
At a first sight, the Multinode support would have the most of the needed
features, but I did not find an example of such an usage, if there is any
example you can point me to, I will be grateful.
Thank you in advance,
Oana Ercus
Hello everyone,
is there a way of setting tags for existing devices via the command line? The "lava-server manage devices update" command does not have a "--tags" parameter, as the "lava-server manage devices add" has.
Mit freundlichen Grüßen / Best regards
Tim Jaacks
DEVELOPMENT ENGINEER
Garz & Fricke GmbH
Tempowerkring 2
21079 Hamburg
Direct: +49 40 791 899 - 55
Fax: +49 40 791899 - 39
tim.jaacks(a)garz-fricke.com
www.garz-fricke.com
SOLUTIONS THAT COMPLETE!
Sitz der Gesellschaft: D-21079 Hamburg
Registergericht: Amtsgericht Hamburg, HRB 60514
Geschäftsführer: Matthias Fricke, Manfred Garz
In lava job definition, boot action can use "connection-namespace" to indicate use previous namespace's connection.Does deploy action have such as "deploy-namespace" to indicate to use previous deploy image?
For example in an application scenario, it need to sequential execution two phases pipeline(deploy,boot,test), it can be solved by define two namespace in job definiton.
When run it executed in serial as : phase1(namespace1) deploy->boot->test -> phase2(namespace2) deploy->boot->test.
If phase2 deploy images(kernel,dtb,rootfs) are exactly same as phase2 deploy images,how to speed up phase2 deploy execution? I guess if deploy action have such as "deploy-namespace" to indicate previous deploy,then phase2 deploy process can be pass.
Before test job,we need to add a "device_type" .jinja2 file to directory /etc/lava-server/dispatcher-config/device-types/,and add a "device" .jinja2 file to /etc/lava-server/dispatcher-config/devices/.
The "device_type" .jinja2 file defines device type(for example different hardware) ,and "device" .jinja2 file(at: /etc/lava-server/dispatcher-config/devices/) defines a concrete device.
When the dispatcher submits job, a job should be submited to a concrete device.But In job defintion file,the description of the related device is only the "device_type" but no "device", why is not "device"?
for example:
# Your first LAVA JOB definition for arm
device_type: arm
job_name: arm pipeline, first job
## why not as:
# Your first LAVA JOB definition for arm
device: arm01
job_name: arm pipeline, first job
https://validation.linaro.org/static/docs/v2/admin-lxc-deploy.html#lxc-depl…
,
It say that LXC devices can run lava tests within a container without
disturbing the dispatcher host.
Does LXC support the arm device? Although LXC may supports to run the arm
virtual machine in PC server,but how does it support the completed arm
device(Including various peripheral interfaces eg ethernet,usb.. ) ?
Because the test job often test various peripheral interfaces,Is LXC
emulating these interfaces?