Hi lava-users,
I upgrade my lava-server package (from backports) to 2019-03 on debian stretch. After this is get an django error:
ERROR 2019-04-04 08:24:16,694 exception Invalid HTTP_HOST header: '<my-host-name>'. You may need to add '<my-host-name>' to ALLOWED_HOSTS.
The browser reports a Bad Request (400)
So I added <my-host-name> and "*" to ALLOWED_HOSTS in /usr/lib/python3/dist-packages/lava_scheduler_app/settings.py and /usr/lib/python3/dist-packages/django/conf/global_settings.py but the error is still present. Are these the wrong file or what could be the problem?
Matthias
Job definition & Detailed log in attachment
发件人: Xiaomingwang (Steve)
发送时间: 2019年4月4日 10:29
收件人: lava-users(a)lists.lavasoftware.org
抄送: Yewenzhong (jackyewenzhong) <jack.yewenzhong(a)huawei.com>; Chenchun (coston) <chenchun7(a)huawei.com>; liucaili (A) <liucaili2(a)huawei.com>
主题: 转发: Lava Issue: API-Error-server.scheduler.all_devices
发件人: liucaili (A)
发送时间: 2019年4月4日 10:24
收件人: Xiaomingwang (Steve) <xiaomingwang1(a)huawei.com<mailto:xiaomingwang1@huawei.com>>
主题: Lava Issue: API-Error-server.scheduler.all_devices
Dear Sir/Madam,
If possible could you please help us analyze the problems encountered in recent Lava tests?
Job definition & Detailed log in the attachment.
lava-dispatcher version: 2018.11+stretch.
The key information is as follows:
python /usr/local/bin/module_deploy.py --DUT cloudgame4_01
Traceback (most recent call last):
File "/usr/local/bin/module_deploy.py", line 37, in <module>
main(args)
File "/usr/local/bin/module_deploy.py", line 30, in main
module = get_module(dut)
File "/usr/local/bin/module_deploy.py", line 14, in get_module
devices_list = server.scheduler.all_devices()
File "/usr/lib/python2.7/xmlrpclib.py", line 1243, in __call__
return self.__send(self.__name, args)
File "/usr/lib/python2.7/xmlrpclib.py", line 1602, in __request
verbose=self.__verbose
File "/usr/lib/python2.7/xmlrpclib.py", line 1283, in request
return self.single_request(host, handler, request_body, verbose)
File "/usr/lib/python2.7/xmlrpclib.py", line 1316, in single_request
return self.parse_response(response)
File "/usr/lib/python2.7/xmlrpclib.py", line 1493, in parse_response
return u.close()
File "/usr/lib/python2.7/xmlrpclib.py", line 800, in close
raise Fault(**self._stack[0])
xmlrpclib.Fault: <Fault -32603: "Internal Server Error (contact server administrator for details): 'NoneType' object has no attribute 'pk'">
Is it a lava bug? We look forward to your reply. Thank you for your assistance.
Best Regards,
Caili Liu
Hi,
I want to measure some output values of test cases. I have a shell script which run stress-ng, parse it's output and exports some measurement variables.
How can I record theses variables? I tried to use lava-test-case -shell myscript.sh -result pass -measurement $VAR1 -unit unit but no values are recorded. Maybe this is the wrong approach, but how can I do this in the correct way?
Matthias
Hello lava users,
how can I run a multinode job on specific devices instead of (a possible set) of device_types? I plan to run CAN or RS485 communication tests which requires a wired connection between duts. Is is possible to submit a job to theses special duts or should is have device_types with only on device instance?
Greetings,
Matthias
Hi Sirs,
Does LAVA support MCU like system? Which usually using a debugger to download image to a MCU internal flash, and get uart result?
Regards,
Hake
How can you have more than one LAVA user have the same token secret
(e.g. for a notify callback.)?
Example use case:
- LAVA job with notify callbacks using token names
- submited as user "bob", token names of "bob" map to actual token secrets
- job fails
- user "lab-admin" fixes some lab issues, re-submits job
- job passes, but callbacks fail because tokens are associated with user "bob"
Since the re-submitted job runs as user "lab-admin", the same token
names and corresponding secrets don't exist.
Naively, user "lab-admin" tries to copy the token secrets from user
"bob" keeping the same token names, but this fails saying that "secret
already exists".
Why can't different users have the same secrets?
I haven't looked at the code, but this limitation kind of suggests that
the secret itself is the key in the db, which would prevent multiple
secrets of the same.
Kevin