+1, we also have same issue, had to pending new version deploy.
Message: 1
Date: Mon, 20 May 2019 05:39:40 +0000
From: Larry Shen <larry.shen(a)nxp.com>
To: "lava-users(a)lists.lavasoftware.org"
<lava-users(a)lists.lavasoftware.org>
Subject: [Lava-users] Why make the decision to limit job context in
lava master?
Message-ID:
<DBBPR04MB63291E1DC4F5F202DEDFE16699060(a)DBBPR04MB6329.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
For 2019.04 version, we see next:
Job context
-----------
The schema validator is now checking the content of the `context` dictionary. Only the following keys are now allowed:
* `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`, `guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`, `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga`
* `bootloader_prompt`, `console_device`, `extra_kernel_args`, `extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`, `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`, `test_character_delay`, `tftp_mac_address`
Jobs using keys that are not listed in this list will be rejected.
We usually set an customized context in job, and in device-type jinja2, use this context to just different value to set proper parameters.
After this limit, all things break!
So, my question is:
lava could be designed to as a framework to give freedom to users to do their things as in the past, why we now enhance so many limits to users?
And additional, and workaround for my scenario?
Regards,
Larry
Hi lava-users,
my Debian machine running lava-server (2019.04) sends mails via msmtp/msmtp-mta. Mails from cron or apt work fine. But I got no mails from lava. Even when I submit a test job with a notify statement.
notify:
criteria:
status: finished
recipients:
- to:
method: email
user: default
verbosity: verbose
The user default uses my real mail address not a system mail address.
This is the Django log:
INFO 2019-05-10 07:18:15,546 notifications [1343] sending email notification to XXXXXXX(a)YYYYYY.com
ERROR 2019-05-10 07:18:15,557 notifications [Errno 99] Cannot assign requested address
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/lava_scheduler_app/notifications.py", line 303, in send_notifications
title, body, settings.SERVER_EMAIL, [recipient.email_address]
File "/usr/lib/python3/dist-packages/django/core/mail/__init__.py", line 62, in send_mail
return mail.send()
File "/usr/lib/python3/dist-packages/django/core/mail/message.py", line 348, in send
return self.get_connection(fail_silently).send_messages([self])
File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py", line 104, in send_messages
new_conn_created = self.open()
File "/usr/lib/python3/dist-packages/django/core/mail/backends/smtp.py", line 64, in open
self.connection = self.connection_class(self.host, self.port, **connection_params)
File "/usr/lib/python3.5/smtplib.py", line 251, in __init__
(code, msg) = self.connect(host, port)
File "/usr/lib/python3.5/smtplib.py", line 335, in connect
self.sock = self._get_socket(host, port, self.timeout)
File "/usr/lib/python3.5/smtplib.py", line 306, in _get_socket
self.source_address)
File "/usr/lib/python3.5/socket.py", line 712, in create_connection
raise err
File "/usr/lib/python3.5/socket.py", line 703, in create_connection
sock.connect(sa)
OSError: [Errno 99] Cannot assign requested address
WARNING 2019-05-10 07:18:15,558 notifications [1343] failed to send email notification to XXXXXXX(a)YYYYYY.com
Lava has a problem with smtp. Is it necessary to have a complete smtp server on the local machine? Or is there a special smtp configuration?
Greetings,
Matthias
For 2019.04 version, we see next:
Job context
-----------
The schema validator is now checking the content of the `context` dictionary. Only the following keys are now allowed:
* `arch`, `boot_console`, `boot_root`, `cpu`, `extra_options`, `guestfs_driveid`, `guestfs_interface`, `guestfs_size`, `machine`, `memory`, `model`, `monitor`, `netdevice`, `serial`, `vga`
* `bootloader_prompt`, `console_device`, `extra_kernel_args`, `extra_nfsroot_args`, `kernel_loglevel`, `kernel_start_message`, `lava_test_results_dir`, `menu_interrupt_prompt`, `mustang_menu_list`, `test_character_delay`, `tftp_mac_address`
Jobs using keys that are not listed in this list will be rejected.
We usually set an customized context in job, and in device-type jinja2, use this context to just different value to set proper parameters.
After this limit, all things break!
So, my question is:
lava could be designed to as a framework to give freedom to users to do their things as in the past, why we now enhance so many limits to users?
And additional, and workaround for my scenario?
Regards,
Larry
Dear users,
I'd like to add metrics to scale my test farm. Basically I would like to check the occupation rate of the active boards in my farm, to be able to decide whether I need to add extra ones or not.
Do you know if there is a simple way to do it?
Best regards,
Denis
The multinode function of "pass data between devices".Note:
"The message data is stored in a cache file which will be overwritten when
the next synchronisation call is made. Ensure that your scripts make use of
(or copy aside) any MultiNode cache data before calling any other MultiNode
API helpers that may clear the cache."
Does it mean follow example:
roler1:
..
steps:
- lava-send ipv4 ip=192
- lava-send ipv4 ip=193
..
roler2:
step2:
- lava-wait ipv4
- ipdata=$(cat /tmp/lava_multi_node_cache.txt | cut -d = -f 2)
..
After run, is content of roler2 ipdata 193?
In trying to run lava-dispatcher inside a docker container and connect a FRDM-K64F board ran into some issues related to the fact that udev events aren’t seen inside the container since we aren’t typically running systemd/udevd there.
I came across this project that will forward udev events from the host to a container that worked pretty well:
https://github.com/eiz/udevfw
I’ve re-implemented this in python for easier development (added some docker awareness):
https://git.lavasoftware.org/galak/docker-compose/blob/lite/contrib/udev-fo…
Right now running udev-forward.py is kinda kludgy. Wanted to get input on how people think this should work, should we make a daemon out of it? Should there be some kinda of config file? Do we think we need to filter events (and if so how)? Need to look at support for multicasting (support sending to multiple dispatchers). Where should this live, in docker-compose repo?
Other thoughts.
- k
Hello,
I have a remote worker that needs to add a new device-type on the
master.
The remote worker has an auth token with admin/staff/superuser
privileges, and lavacli configured with that token, but when I attempt
to set the new template, I get permission denied:
# lavacli device-types template set da850-lcdk /tmp/new-device-type.jinja2
Unable to call 'device-types.template': <Fault 400: 'Unable to write device-type configuration: Permission denied'>
What permissions am I missing?
Kevin
Hi!
I'm seeing the following issue with lavasoftware/lava-server:2019.04:
http://localhost/static/docs/v2/ gives "Forbidden". Apache log shows the
following:
[Mon May 06 17:57:42.206713 2019] [autoindex:error] [pid 766:tid 140404225701632] [client 172.18.0.1:46780] AH01276: Cannot serve directory /usr/share/lava-server/static/docs/v2/: No matching DirectoryIndex (index.html,index.cgi,index.pl,index.php,index.xhtml,index.htm) found, and server-generated directory index forbidden by Options directive, referer: http://localhost/
The easiest way to reproduce is to run:
$ docker run --rm -p 80:80 -it lavasoftware/lava-server:2019.04
And load http://localhost/static/docs/v2/
Change 2019.04 to 2019.03 and it works fine.
I didn't see anything about this mentioned in the release announcement.
I guess the apache config needs some update?
Thanks!
Dan
