lava-users

lava-users@lists.lavasoftware.org

1 participants
940 discussions

Troubles using custom notification client

by David Lewin

Hi, >From a client side, I'd like to be notified that jobs are achieved in a distant lava server. I started with the example provided at https://validation.linaro.org/static/docs/v2/data-export.html#write-your-ow… 1. In a 1st try I've changed the example - because I'm using port 10080 - and it works without the <lookup_publisher> . For that, I've hard coded the url returned by lookup_publisher but this only prints out one status at a time, ie :I needed to restart the script each time to have updates : "Submited"->*Ctrl-C*->Running->*Ctrl-C*->complete 2. In a 2nd time I've tried to implement lookup_publisher thinking the status would be updated automatically. In that case it wants to connect to 5500 and obviously fails after timeout import xmlrpclib > > import argparse > import yaml > import signal > import zmq > import xmlrpclib > from urlparse import urlsplit > > > FINISHED_JOB_STATUS = ["Complete", "Incomplete", "Canceled"] > > token = "mytoken" > username = "username" > #hostname = "lava-server:10080" > > > class JobEndTimeoutError(Exception): > """ Raise when the specified job does not finish in certain timeframe. > """ > > > class Timeout(object): > """ Timeout error class with ALARM signal. Accepts time in seconds. """ > class TimeoutError(Exception): > pass > > def __init__(self, sec): > self.sec = sec > > def __enter__(self): > signal.signal(signal.SIGALRM, self.timeout_raise) > signal.alarm(self.sec) > > def __exit__(self, *args): > signal.alarm(0) > > def timeout_raise(self, *args): > raise Timeout.TimeoutError() > > > class JobListener(object): > > def __init__(self, url): > self.context = zmq.Context.instance() > self.sock = self.context.socket(zmq.SUB) > > self.sock.setsockopt(zmq.SUBSCRIBE, b"") > self.sock.connect(url) > > def wait_for_job_end(self, job_id, timeout=None): > > try: > with Timeout(timeout): > while True: > msg = self.sock.recv_multipart() > try: > (topic, uuid, dt, username, data) = msg[:] > except IndexError: > # Droping invalid message > continue > > data = yaml.safe_load(data) > if "job" in data: > if data["job"] == job_id: > if data["status"] in FINISHED_JOB_STATUS: > return data > > except Timeout.TimeoutError: > raise JobEndTimeoutError( > "JobListener timed out after %s seconds." % timeout) > > def lookup_publisher(hostname): > """ > Lookup the publisher details using XML-RPC > on the specified hostname. > """ > xmlrpc_url = "http://%s:10080/RPC2" % (hostname) > server = xmlrpclib.ServerProxy(xmlrpc_url) > socket = server.scheduler.get_publisher_event_socket() > port = urlsplit(socket).port > listener_url = 'tcp://%s:%s' % (hostname,port) > print("Using %s" % listener_url) > return listener_url > > > > if __name__ == '__main__': > # timeout=1200 > > parser = argparse.ArgumentParser() > parser.add_argument("-j", "--job-id", type=int, help="Job ID to wait > for") > parser.add_argument("-t", "--timeout", type=int, help="Timeout in > seconds") > parser.add_argument("--hostname", help="hostname of the instance") > > options = parser.parse_args() > > # server = xmlrpclib.ServerProxy("http://%s:%s@%s/RPC2" % (username, > token, hostname)) > > #print(server.system.listMethods()) > # ret_status=server.scheduler.job_status(options.job_id) > # print (ret_status['job_status']) > > #publisher = 'tcp://%s' % (hostname) > publisher = lookup_publisher(options.hostname) > > listener = JobListener(publisher) > listener.wait_for_job_end(options.job_id, options.timeout) > >

8 years, 1 month

help: can't use specific branch of a test definition repository

by Xu, Hongyu

Hi all , I have saw the doc about : https://validation.linaro.org/static/docs/v2/test-repositories.html#test-re…! My test-definition is in the brach dev-br1, not the master . So I point the branch in my yaml file, but it do noting ! Why? Please give me some help? Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

8 years, 1 month

Problem with LAVA 2017.12

by LABBE Corentin

Hello I have installed a fresh 2017.12 in a docker and I hit two problem: - With the exception of lava-coordinator, all services (lava-master, lava-server, lava-slave, etc...) fail to start with: service lava-xxxx start lava-xxxx: unrecognized service All Other service successfully start (postgresql, apache2) - I have then re-added old init scripts and when I add a worker with: "lava-server manage workers add lab-slave" I get: Traceback (most recent call last): File "/usr/bin/lava-server", line 78, in <module> main() File "/usr/bin/lava-server", line 74, in main execute_from_command_line(django_options) File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 367, in execute_from_command_line utility.execute() File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", line 359, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 294, in run_from_argv self.execute(*args, **cmd_options) File "/usr/lib/python2.7/dist-packages/django/core/management/base.py", line 345, in execute output = self.handle(*args, **options) File "/usr/lib/python2.7/dist-packages/lava_server/management/commands/workers.py", line 77, in handle options["disabled"]) KeyError: 'disabled' iNote that before I have successfully done commands like adding user or device-types Regards

8 years, 2 months

Device Integration Stories - request for contributions

by Neil Williams

Possibly the hardest thing that can be done with LAVA is to integrate a new device-type. Every story is different, every device has it's own issues. The LAVA software team would like to build a history of integration stories to document the recovery process, provide integration hints for others, build a wider picture of the requirements of automation across the ecosystem. A key part of any device integration is how to recover a device which has been taken offline by a broken build or broken test action. It is rare that a new device is suitable for LAVA directly out of the box, there are usually firmware updates, configuration changes, jumper settings or other mods required. Each of these steps needs to be documented so that someone else can integrate the same board into their instance and the same steps are useful when recovering a bricked device. Having the Jinja2 template is not usually enough. (As a side note on that, we do welcome all contributions of new jinja2 templates. The one place where everyone looks for new device-type support is lava_scheduler_app/tests/device-types/ in the master branch of http://git.linaro.org/lava/lava-server.git. If you have integrated a device-type which does not exist in that directory, please follow the contribution guidelines in the documentation and submit your Jinja2 template for review.) https://git.linaro.org/lava/lava-server.git/tree/lava_scheduler_app/tests/d… Recent device integrations in LAVA are documented through a process of comments on JIRA stories (all LAVA JIRA stories are accessible anonymously). Sometimes this turns out to be trial and error, so sometimes a README document or similar is created for easy reference. I'll post some of our recovery README documents on this thread later. This is a request for contributions of your integration stories, your device recovery README documents and your input on what are the minimum requirements for automation in general. It doesn't matter how unusual the hardware or how commonplace. It doesn't matter if it took months to integrate or days. Someone may need your information to setup the same device in their instance. If your device is available on the open market, someone could be thinking of how to automate it. Please post your recovery README texts, integration stories here. This list is publicly archived, so this should make it easy for others to find your contribution in their favourite search engine. In future, as well as unit tests, the LAVA software team may ask for the recovery notes and integration story to be posted here when reviewing contributions of Jinja2 templates. -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

8 years, 2 months

Setting the "inactivity timeout" parameter

by Dragos Iorgulescu

Hello! Is there a way to set/override/disable the inactivity timeout? While working with a (sometimes) slower board, we end up with "Terminal.stop: Inactivity timeout." . I believe this might have to do with the fact that the board fails to respond in a timely fashion and LAVA marks this as hung. While searching for this in the docs, I only found a reference for hacking sessions. Kind regards, Dragos

8 years, 2 months

rootfs resize in LAVA2

by Dragos Iorgulescu

Hi everyone! Does LAVA offer a way to resize rootfs images (“ramdisk_files”, as they are referred to in the code) before deploying them? We are working with our own Linux distro on a Cavium board and we need to resize the rootfs image (which is ext4) after the test overlays are added by LAVA. This step is necessary since we need to run a series of community tests that imply a large number of package dependencies. Also, we do not want to resize the whole image by default, since this will have other CI storage side effects and, also, some policy implications (that I am not really aware of 😊). Anyway, we are currently looking at adding/altering apply_overlay.py (pipeline/actions/) in order to run a resize2fs command after the “updated” ramdisk is unmounted. Just wondering if there is already a more elegant way of doing this. We are also considering making some extensions and maybe get to the point where we could specify this type of requirement in the device dictionary or the device template itself, and then specific code would be executed only if such a setting would be encountered at runtime, but that remains to be discussed. Thanks in advance! Dragoș

8 years, 2 months

Local lava test

by Denis HUMEAU

Dear all, I'm quite sure I've seen somewhere in Lava documentation an article explaining how to replay some Lava jobs in a local mode, but I can't find this piece of information anymore. By local mode, I mean: - DUT at the developer desk, not in the test farm - Jobs available on a Lava server - Developer wants to replay/modify locally a job Can you share any link or help on this? Many thanks, Denis

8 years, 2 months

Customizing the deployment and booting actions

by Ros Dos Santos, Alfonso (CT RDA DS EVO OPS DIA SE 1)

Hello everyone, in our current project we have some devices that are not "directly" supported by lava. I would like to ask for you opinion on which would be the correct way to proceed. The main problem is that our devices have a EFI implementation in the firmware that is making the task of installing uboot very hard. To avoid this, we thought about serving the image through an "emulated" usb stick. On that regard, we made some progress by setting up a secondary device that would use the linux g_mass_storage module to serve the image through the USB otg port. Our setup is then: 1) The actual testing device 2) The secondary device which only serves the image with g_mass_storage 3) The host machine running the lava-slave application. We thought that we could add a new device-type template to the lava server that would somehow override the deployment and boot actions to address our setup. We tried to look into the base.jinja2 file for some sort of entry point that would allow us to, for example, run a script that would first send the image to the secondary device and secondly run the g_mass_storage module with the image file. Unfortunately, it is still not clear for us how exactly we could inject/override those steps and ignore for instance the boot loader commands. The first question would be, are we going in the right direction? Is there any piece of documentation that would describe a similar problem? What would be your recommendations on this topic? thanks a lot in advance. Best, Alfonso

8 years, 2 months

how to add the overlay to my os, start the test definition

by Xu, Hongyu

Hi , I deploy the device with grub(uefi) method. Now it can interrupt to grub>, and run the boot cmd and auto login. I use the pxe iso installation boot or the sata boot, not the nfs boot. But the lava-overlay file only add into ramdisk(initrd.img), it will disappear when os bootup. So I use the transfer_overlay in my job , but it do nothing, the test shell can't be find . Please give me some help! Job.yaml: actions: - deploy: to: tftp kernel: url: http://swlab004/1680141/vmlinuz-4.11.0-7.1.hxt.aarch64 type: zimage ramdisk: url: http://swlab004/1680141/initramfs-4.11.0-7.1.hxt.aarch64.img compression: gz install_overlay: false preseed: url: http://swlab004/centos7/anaconda-ks_1026.cfg os: centos timeout: minutes: 5 - boot: timeout: minutes: 200 connection: serial method: uefi-menu commands: ramdisk_boot auto_login: login_prompt: ".* login:" username: root password_prompt: 'Password:' password: root transfer_overlay: download_command: ifconfig;wget -S --progress=dot:giga unpack_command: tar -C / -xzf prompts: - 'Last login: .*' - '[root@.* .*]#' parameters: shutdown-message: "reboot: Restarting system" - test: timeout: minutes: 50 definitions: - repository: metadata: format: Lava-Test Test Definition 1.0 name: smoke-tests-basic description: "Basic system test command for Linaro Ubuntu images. The test runs basic commands like pwd, uname, vmstat, ifconfig, lscpu, lsusb and lsb_release." maintainer: - hongyu.xu(a)hxt-semitech.com os: - centos scope: - functional run: steps: - echo "test1a:" "pass" from: inline name: smoke-tests1 path: inline/smoke-tests.yaml Best Regards XuHongyu This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.

8 years, 2 months

LAVA and Mender

by Arnstein Kleven

Greetings, my embedded system is using Mender for over-the-air updates. The way Mender works is that the embedded system needs to have to rootfs partitions, where one is actively being used, and the other is written to when a over-the-air update is initiated. After the new rootfs is written, Mender will change a variable in the bootloader environment and reboot, so that the system boots into the new rootfs. If there is a problem booting into the new rootfs, the bootloader will be set to boot into the old one again. Has anyone here written LAVA tests for systems that use Mender? If so, have you experienced that Mender has complicated the test automation? Any Mender boot test templates would also be appreciated. -- Kind regards, Arnstein Kleven

8 years, 2 months

← Newer
1
...
75
76
77
78
79
80
81
...
94
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

lava-users