On 26 Sep 2017 2:59 am, "Daniel Sangorrin" <daniel.sangorrin(a)toshiba.co.jp>
wrote:
Hi Neil,
> -----Original Message-----
> From: Neil Williams [mailto:neil.williams@linaro.org]
> Sent: Tuesday, September 12, 2017 5:49 PM
> To: Daniel Sangorrin
> Cc: Robert Marshall; Lava Users Mailman list
> Subject: Re: [Lava-users] Help running an inline test
>
> On 12 September 2017 at 09:25, Daniel Sangorrin
> <daniel.sangorrin(a)toshiba.co.jp> wrote:
> >
> >> -----Original Message-----
> >> From: Neil Williams [mailto:neil.williams@linaro.org]
> >> Sent: Tuesday, September 12, 2017 4:58 PM
> >> To: Daniel Sangorrin
> >> Cc: Robert Marshall; Lava Users Mailman list
> >> Subject: Re: [Lava-users] Help running an inline test
> >>
> >> On 12 September 2017 at 08:50, Daniel Sangorrin
> >> <daniel.sangorrin(a)toshiba.co.jp> wrote:
> >> > Hi Neil,
> >> >
> >> > Thanks for your reply.
> >> >
> >> >> -----Original Message-----
> >> >> From: Neil Williams [mailto:neil.williams@linaro.org]
> >> >> Sent: Tuesday, September 12, 2017 4:16 PM
> >> >> To: Daniel Sangorrin
> >> >> Cc: Robert Marshall; Lava Users Mailman list
> >> >> Subject: Re: [Lava-users] Help running an inline test
> >> >>
> >> >> On 12 September 2017 at 08:10, Daniel Sangorrin
> >> >> <daniel.sangorrin(a)toshiba.co.jp> wrote:
> >> >> > Robert, Neil:
> >> >> >
> >> >> > I managed to prepare a 2017.7 environment. The boot action still
works fine.
> >> >> > The test action still fails, but in a more 'sane' way I would say.
> >> >> > There are strange things like 'None', no lava-test-runner, etc..
Please check the
> >> >> > log attached.
> >> >>
> >> >> You haven't specified a deploy step, so there is no test shell
> >> >> created. Boot just does the boot - to deploy the test environment
> >> >> there must be a deploy action.
> >> >
> >> > As far as I understand, the deployment action occurs before the
> >> > boot action and consists of preparing a kernel/filesystem in some
> >> > media (e.g.: as a network filesystem).
> >> > Ref: https://validation.linaro.org/static/docs/v2/actions-deploy.html
> >> >
> >> > For now, I wanted to run my tests with the kernel and filesystem
> >> > that is already installed on the Flash memory. Is this impossible
with LAVA?
> >>
> >> Such a system can only be booted, it cannot operate a Lava Test Shell
> >> because there is no way to get the test shell onto the device without
> >> a deploy.
> >>
> >> There is support for primary connections using SSH
> >> https://validation.linaro.org/static/docs/v2/dispatcher-
design.html#primary-connection
> >>
> >> See: Problems with simplistic testing in the documentation.
> >> https://validation.linaro.org/static/docs/v2/simple-admin.
html#problems-with-simplistic-testing
> >
> > Thanks a lot Neil.
> > # I'm not against deployment, I just wanted to prepare the environment
step by step.
> >
> > The primary connection could be a good solution but it looks like I
wouldn't be able to use the PDU,
> > or the autologin features from the u-boot action through the serial
port. I will implement the
> > deploy action instead.
> >
> > By the way, when you talk about "test shell" I am assuming that you
mean a shell script or binary
> > that is copied into the target filesystem and executed. Is that correct?
> > My filesystem is very minimal: basically busybox using the ash shell.
>
> "test shell" == Lava Test Shell as defined by the test action block.
> This relies on POSIX behaviour where the automation drives scripts
> installed onto the system to execute the test operations themselves.
>
> To handle busybox ash compatibility, just set the Operating System as
> Open Embedded.
>
> actions:
> - deploy:
> # ... rest of the deploy
> os: oe
>
> https://validation.linaro.org/static/docs/v2/actions-deploy.html#index-18
Sorry, it took me a while but I finally got it working.
I met several problems. Some of them were a matter of overriding variables.
For example,
I cannot use dhcp for the board so I had to change uboot_ipaddr_cmd and
base_ip_args.
There was one variable (SERVER_IP) I couldn't override, so I had to modify
base-uboot.jinja2 for it.
my jinja2:
{% set uboot_serverip = '192.168.1.66' %}
base-uboot.jinja2
# vi /etc/lava-server/dispatcher-config/device-types/base-uboot.jinja2
{% set base_uboot_tftp_bootcmd = uboot_tftp_bootcmd|default(
" - setenv bootcmd '" + uboot_ipaddr_cmd|default('dhcp') + ";
setenv serverip " + uboot_serverip|default('{SERVER_IP}') + "; run
loadkernel; run loadinitrd; " + run_load_fdt +
uboot_bootx_cmd|default('{BOOTX}')
+ "'
- run bootcmd") -%}
Note: I tried modifying LAVA_SERVER_IP and LAVA_NETWORK_IFACE in
/etc/lava-dispatcher/lava-dispatcher.conf as well but it didn't work.
Those settings are only relevant for V1, so V2 tests will ignore these.
Setting the SERVER_IP in the device configuration is the wrong approach.
This IP address is for the dispatcher, so it needs to be added to the
dispatcher configuration. In V2, the dispatcher configuration is sent from
the master.
Setting a fixed IP address for the dispatcher is already supported.
See /usr/share/lava-dispatcher/dispatcher.yaml for an example.
See
https://validation.linaro.org/static/docs/v2/pipeline-admin.html#extra-disp…
You need a file named according to the hostname of the dispatcher as it
appears in the dispatcher-master log file.
If you consider it useful, please consider including it in the mainstream
code.
Thanks for your help,
Daniel
> >> >> >> -----Original Message-----
> >> >> >> From: Lava-users [mailto:lava-users-bounces@lists.linaro.org] On
Behalf Of Daniel Sangorrin
> >> >> >> Sent: Monday, September 11, 2017 5:16 PM
> >> >> >> To: 'Robert Marshall'; 'Lava Users Mailman list'
> >> >> >> Subject: Re: [Lava-users] Help running an inline test
> >> >> >>
> >> >> >> > -----Original Message-----
> >> >> >> > From: Lava-users [mailto:lava-users-bounces@lists.linaro.org]
On Behalf Of Robert Marshall
> >> >> >> > Sent: Monday, September 11, 2017 4:47 PM
> >> >> >> > To: 'Lava Users Mailman list'
> >> >> >> > Subject: Re: [Lava-users] Help running an inline test
> >> >> >> >
> >> >> >> > "Daniel Sangorrin" <daniel.sangorrin(a)toshiba.co.jp> writes:
> >> >> >> >
> >> >> >> > > Hi Neil,
> >> >> >> > >
> >> >> >> > > Thanks for your quick reply.
> >> >> >> > >
> >> >> >> > >> -----Original Message-----
> >> >> >> > >> From: Neil Williams [mailto:neil.williams@linaro.org]
> >> >> >> > >> Sent: Monday, September 11, 2017 3:23 PM
> >> >> >> > >>
> >> >> >> > >> On 11 September 2017 at 07:06, Daniel Sangorrin
> >> >> >> > >> <daniel.sangorrin(a)toshiba.co.jp> wrote:
> >> >> >> > >> > Hi,
> >> >> >> > >> >
> >> >> >> > >> > I have spent a few days learning LAVA with QEMU and the
Beagle Bone black.
> >> >> >> > >> > Now, I'm trying to setup a Renesas iwg20m board but I
have some strange
> >> >> >> > >> > problem.
> >> >> >> > >> > # I'm using LAVA v2016.12.
> >> >> >> > >>
> >> >> >> > >> Updates are available - you should follow the LAVA
documentation for
> >> >> >> > >> the LAVA repositories and upgrade.
> >> >> >> > >>
> >> >> >> > >> https://staging.validation.linaro.org/static/docs/v2/
installing_on_debian.html#lava-repositories
> >> >> >> > >
> >> >> >> > > Thanks, I will try with the 2017.9 version then.
> >> >> >> > >
> >> >> >> > Daniel
> >> >> >> >
> >> >> >> > If you're doing the test within b@d [1] you should look at my
> >> >> >> > https://gitlab.com/rajm/board-at-desk-single-dev/tree/
lava2017-fixes
> >> >> >> > branch which has various fixes for our use of lava 2017-7,
once that
> >> >> >> > branch is merged - soon now! - it should 'just work'
> >> >> >>
> >> >> >> Wow Robert, just in time! Thanks.
> >> >> >>
> >> >> >> Daniel
> >> >> >>
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Lava-users mailing list
> >> >> >> Lava-users(a)lists.linaro.org
> >> >> >> https://lists.linaro.org/mailman/listinfo/lava-users
> >> >> >
> >> >> > _______________________________________________
> >> >> > Lava-users mailing list
> >> >> > Lava-users(a)lists.linaro.org
> >> >> > https://lists.linaro.org/mailman/listinfo/lava-users
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> Neil Williams
> >> >> =============
> >> >> neil.williams(a)linaro.org
> >> >> http://www.linux.codehelp.co.uk/
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> Neil Williams
> >> =============
> >> neil.williams(a)linaro.org
> >> http://www.linux.codehelp.co.uk/
> >
> >
> >
>
>
>
> --
>
> Neil Williams
> =============
> neil.williams(a)linaro.org
> http://www.linux.codehelp.co.uk/
Hi lava experts :
The branch did not take effect when I specified the branch in my test-definition! (hxt-dev-br1)
I use the local git repo , and my test-definition is in branch :hxt-dev-br1, not the master. Then I specified the branch, but it did not take effect.
My test-definition:
device_type: qemu
job_name: health check job
timeouts:
job:
minutes: 15
action:
minutes: 5
connection:
minutes: 2
priority: medium
visibility: public
# context allows specific values to be overridden or included
context:
# tell the qemu template which architecture is being tested
# the template uses that to ensure that qemu-system-x86_64 is executed.
arch: amd64
metadata:
# please change these fields when modifying this job for your own tests.
docs-source: first-job
docs-filename: qemu-pipeline-first-job.yaml
# ACTION_BLOCK
actions:
- deploy:
timeout:
minutes: 90
to: tmpfs
images:
rootfs:
image_arg: -drive format=raw,file={rootfs}
url: http://autotest002/tmp/stretch-2.img.gz
compression: gz
os: debian
# BOOT_BLOCK
- boot:
timeout:
minutes: 2
method: qemu
media: tmpfs
prompts: ["root@debian:"]
auto_login:
login_prompt: "login:"
username: root
- test:
timeout:
minutes: 30
definitions:
- repository: ssh://1680141@10.5.20.24:29418/sw_test/test-definitions
from: git
path: ubuntu/smoke-tests-basic.yaml
name: smoke-tests-basic
branch: hxt-dev-br1
Log:
Loading test definitionsstart: 1.3.3.1 git-repo-action (timeout 00:14:55)Using /lava-48 at stage 0Fetching tests from ssh://1680141@10.5.20.24:29418/sw_test/test-definitionsRunning '/usr/bin/git clone ssh://1680141@10.5.20.24:29418/sw_test/test-definitions /var/lib/lava/dispatcher/tmp/48/lava-overlay-Iw36n8/lava-48/0/tests/0_smoke-tests-basic'Tests stored (tmp) in /var/lib/lava/dispatcher/tmp/48/lava-overlay-Iw36n8/lava-48/0/tests/0_smoke-tests-basic/ubuntu/smoke-tests-basic.yamlUnable to open test definition 'ubuntu/smoke-tests-basic.yaml': [Errno 2] No such file or directory: '/var/lib/lava/dispatcher/tmp/48/lava-overlay-Iw36n8/lava-48/0/tests/0_smoke-tests-basic/ubuntu/smoke-tests-basic.yaml'
Best Regards
XuHongyu
From: Lava-users [mailto:lava-users-bounces@lists.linaro.org] On Behalf Of Xu, Hongyu
Sent: 2017年9月18日 18:07
To: Lava-users(a)lists.linaro.org
Subject: [Lava-users] test-definitions
Hi lava ,
Can I put test-definitions(.yaml script ) in locally on my worker server ? Don’t get them from the git-repo!
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.
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.
Hi lava ,
Can I put test-definitions(.yaml script ) in locally on my worker server ? Don't get them from the git-repo!
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.
Hi experts,
It's error when I auth token with the lava-too, because my I deploy the lava 2017.7 with SSL Self-signed certificate. Now I can use the XML-RPC to auth the token with " ssl._create_unverified_context ". How can I do ? I want use the lava-tool .
import ssl
ssl._create_default_https_context = ssl._create_unverified_context
import xmlrpclib
username = "lavaadmin"
token = "onku07n16r2uktjz40otgn0n9m7q1bp1b75dr4u0ph0juy7jnb8csi0u9x7fg3sf1mpgnxw00sq1otmzl3rqpdu4tl5fam45m5xyt25oin020ohkajzrx7ze0aaukkdt"
hostname = "autotest001"
protocol = "https" # http or preferably https
server = xmlrpclib.ServerProxy("%s://%s:%s@%s/RPC2" % (protocol, username, token, hostname))
device_hostname = "qemu_test01"
jinjia_string = " {% extends 'qemu.jinja2' %} {% set mac_addr = '52:54:00:12:34:60' %} {% set memory = '1024' %} "
> lava-tool auth-add --token-file /home/lavaadmin/xuhy/qemu_test_token https://1680141@10.5.21.5/RPC2
>
> ERROR: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate
> verify failed (_ssl.c:661)>
Best Regards
XuHongyu
-----Original Message-----
From: Xu, Hongyu
Sent: 2017年9月12日 14:47
To: 'Neil Williams' <neil.williams(a)linaro.org>
Cc: Lava-users(a)lists.linaro.org
Subject: RE: [Lava-users] auth token
We deploy the lava on the Internal lan, an the domain names is private . But let's Encrypt can only issue certificates for valid public domain names. Are there any other Suggestions?
Best Regards
XuHongyu
-----Original Message-----
From: Neil Williams [mailto:neil.williams@linaro.org]
Sent: 2017年9月11日 15:35
To: Xu, Hongyu <hongyu.xu(a)hxt-semitech.com>
Cc: Lava-users(a)lists.linaro.org
Subject: Re: [Lava-users] auth token
On 11 September 2017 at 08:28, Xu, Hongyu <hongyu.xu(a)hxt-semitech.com> wrote:
> Hi lava experts:
>
>
>
> I deploy the lava 2017.7 with SSL Self-signed certificate, then I
> want to create the device-dictionary for the qemu devices, it’s error
> when I add auth_token. Please give me some suggest!
>
>
That needs to be fixed within your own SSL configuration. Lots of security packages have issues with self-signed certificates, so it is better to look at solutions like letsencrypt. Details of how this is configured are outside the scope of the lava-users mailing list, it's a general system admin task and a variety of guides are available online.
>
> lava-tool auth-add --token-file /home/lavaadmin/xuhy/qemu_test_token
> --user-shortcut 1680141 --endpoint-shortcut qemu_test01
> https://1680141@10.5.21.5
>
> ERROR: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate
> verify failed (_ssl.c:661)>
>
>
>
> Best Regards
>
>
>
> XuHongyu
>
>
>
> From: Xu, Hongyu
> Sent: 2017年9月4日 14:41
> To: 'Lava-users(a)lists.linaro.org' <Lava-users(a)lists.linaro.org>
> Subject: Local Django user accounts
>
>
>
>
>
> Hi all,
>
>
>
> I have installed the lava-serer (2017.7) on my DEBIAN 9.10. But now
> I can’t sign in with the local Django user, this is the error infomations:
>
> Forbidden (403)
>
> CSRF verification failed. Request aborted.
>
> You are seeing this message because this site requires a CSRF cookie
> when submitting forms. This cookie is required for security reasons,
> to ensure that your browser is not being hijacked by third parties.
>
> If you have configured your browser to disable cookies, please
> re-enable them, at least for this site, or for 'same-origin' requests.
>
> More information is available with DEBUG=True.
>
>
This is already covered in the documentation, it's a Django change. If you have tried to solve this by using a self-signed certificate on localhost, you should avoid trying to create https://localhost/ and just update the security settings:
https://staging.validation.linaro.org/static/docs/v2/pipeline-debug.html?hi…
>
> Please give me some advices!
>
>
>
> root@hxtcorp:~# dpkg-query -l lava*
>
> Desired=Unknown/Install/Remove/Purge/Hold
>
> |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Tri
> g-pend
>
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>
> ||/ Name Version Architecture
> Description
>
> +++-=================================-=====================-==========
> +++===========-=======================================================
> +++================
>
> ii lava-coordinator 0.1.7-1 all
> LAVA Coordinator daemon
>
> un lava-dashboard <none> <none>
> (no description available)
>
> un lava-dashboard-tool <none> <none>
> (no description available)
>
> ii lava-dispatcher 2017.7-1~bpo9+1 amd64
> Linaro Automated Validation Architecture dispatcher
>
> un lava-scheduler <none> <none>
> (no description available)
>
> un lava-scheduler-tool <none> <none>
> (no description available)
>
> ii lava-server 2017.7-1~bpo9+1 all
> Linaro Automated Validation Architecture server
>
> ii lava-server-doc 2017.7-1~bpo9+1 all
> Linaro Automated Validation Architecture documentation
>
> ii lava-tool 0.21-1 all
> command line utility for LAVA
>
> un lavapdu <none> <none>
> (no description available)
>
> ii lavapdu-client 0.0.5-1 all
> LAVA PDU client
>
> ii lavapdu-daemon 0.0.5-1 all
> LAVA PDU control daemon
>
>
>
> add the local Django user:
>
> sudo lava-server manage createsuperuser --username $USERNAME
> --email=$EMAIL
>
> sudo lava-server manage authorize_superuser --username $USERNAME
>
>
>
> root@hxtcorp:/etc/lava-server# lava-server manage users list
>
> List of users:
>
> * 1680077
>
> * 1680141
>
> * lava-health
>
> * xuhy
>
>
>
> 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.
>
>
>
>
> _______________________________________________
> Lava-users mailing list
> Lava-users(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lava-users
>
--
Neil Williams
=============
neil.williams(a)linaro.org
http://www.linux.codehelp.co.uk/
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.
Hi，Neil：
I want to control device power on/off by lavapdu.,but when I run pduclient --daemon autotest001 --hostname 10.5.142.6 --command off --port 10
ERROR : Error sending command, wrong daemon hostname?
Can you help me solve this problem?
Lava-server :IP 10.5.21.5 autotest001
Pdudaemon run on the lava-server
Lavapdu.conf:
{
"daemon": {
"hostname": "10.5.21.5",
"port": 16421,
"dbhost": "127.0.0.1",
"dbuser": "pdudaemon",
"dbpass": "pdudaemon",
"dbname": "lavapdu",
"retries": 5,
"logging_level": "INFO"
},
"pdus": {
"192.168.10.2": {
"driver": "apc9210"
},
"192.168.10.3": {
"driver": "apc7952",
"telnetport": 5023
},
"192.168.10.4": {
"driver": "apc7952"
},
"192.168.10.5": {
"driver": "apc8959",
"this": "that",
"something": "else"
},
"192.168.25.52": {
"driver": "apc7952"
}
}
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.
Hi lava experts:
I deploy the lava 2017.7 with SSL Self-signed certificate, then I want to create the device-dictionary for the qemu devices, it’s error when I add auth_token. Please give me some suggest!
lava-tool auth-add --token-file /home/lavaadmin/xuhy/qemu_test_token --user-shortcut 1680141 --endpoint-shortcut qemu_test01 https://1680141@10.5.21.5
ERROR: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)>
Best Regards
XuHongyu
From: Xu, Hongyu
Sent: 2017年9月4日 14:41
To: 'Lava-users(a)lists.linaro.org' <Lava-users(a)lists.linaro.org>
Subject: Local Django user accounts
Hi all,
I have installed the lava-serer (2017.7) on my DEBIAN 9.10. But now I can’t sign in with the local Django user, this is the error infomations:
Forbidden (403)
CSRF verification failed. Request aborted.
You are seeing this message because this site requires a CSRF cookie when submitting forms. This cookie is required for security reasons, to ensure that your browser is not being hijacked by third parties.
If you have configured your browser to disable cookies, please re-enable them, at least for this site, or for 'same-origin' requests.
More information is available with DEBUG=True.
Please give me some advices!
root@hxtcorp:~# dpkg-query -l lava*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=================================-=====================-=====================-=======================================================================
ii lava-coordinator 0.1.7-1 all LAVA Coordinator daemon
un lava-dashboard <none> <none> (no description available)
un lava-dashboard-tool <none> <none> (no description available)
ii lava-dispatcher 2017.7-1~bpo9+1 amd64 Linaro Automated Validation Architecture dispatcher
un lava-scheduler <none> <none> (no description available)
un lava-scheduler-tool <none> <none> (no description available)
ii lava-server 2017.7-1~bpo9+1 all Linaro Automated Validation Architecture server
ii lava-server-doc 2017.7-1~bpo9+1 all Linaro Automated Validation Architecture documentation
ii lava-tool 0.21-1 all command line utility for LAVA
un lavapdu <none> <none> (no description available)
ii lavapdu-client 0.0.5-1 all LAVA PDU client
ii lavapdu-daemon 0.0.5-1 all LAVA PDU control daemon
add the local Django user:
sudo lava-server manage createsuperuser --username $USERNAME --email=$EMAIL
sudo lava-server manage authorize_superuser --username $USERNAME
root@hxtcorp:/etc/lava-server# lava-server manage users list
List of users:
* 1680077
* 1680141
* lava-health
* xuhy
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.
Hi,
I upgraded to LAVA 2017.7 (for now I'm using https://github.com/kernelci/lava-docker) and
managed to add my device-type and device as follows:
# Note: I didn't know how to update to 2017.9
docker# lava-server manage device-types add renesas-iwg20m
docker# lava-server manage devices add --device-type renesas-iwg20m --worker lava-docker iwg20m01
However, when I want to add the device dictionary I get an error.
# Note: I am following https://validation.linaro.org/static/docs/v2/pipeline-admin.html
First, I tried with "lava-server manage device-dictionary" as in the documentation, but I failed:
docker# lava-server manage device-dictionary
Unknown command: 'device-dictionary'
Is this only available in the 2017.9 version?
Then, I tried with " lava-tool device-dictionary localhost lava-docker --update myiwg20m.jinja2" but I
get:
Updating device dictionary for lava-docker on localhost
ERROR: Endpoint URL not found in the authorization list: localhost
[Note] my lava-tool is version 0.23-1 (the newest according to apt)
Now, there is a section saying "Using the command line
The device dictionary exists as a jinja2 file in /etc/lava-server/dispatcher-config/devices and can be updated by admins with the necessary access.".
Is this equivalent to using lava-server o lava-tool to install a device dictionary??
Others:
- I confirmed that Pipeline device? is checked.
- Django administration > Devices: what is the meaning of Hostname? I have a value of iwg20m01 (the name of the device),
there is no relation with the server/container's hostname, is there?
- There is an authentication token for the user 'kernel-ci'
Thanks,
Daniel
Hello,
My question looks pretty silly, but as Lava has a big set of features that I haven't discovered yet, I dare ask.
Lava is designed for automatic testing. But everything cannot be fully automated, at least in a reasonable development time frame. More precisely, tests execution can be automated, but the test result needs to be given by a tester. This will happen for example in display or graphics tests.
So, is there a simple way in Lava to let a tester give a manual test result, during or after the test execution? I already have in mind pretty complicated solutions based on Multinode, but simple is key here
Thanks,
Denis
