Hi,
Till now the wa2-lava [1] repository was used as a single point for
integrating LAVA and Workload Automation. The downside of it was that
the integration was pretty specific to one use case we had. The
decision was made that generic support for WA will be moved to
test-definitions [2]. The test-definions will not host any WA agenda
files. They will be still hosted in wa2-lava. This means that purpose
of wa2-lava repository will change. It will act as a 'test plan' place
for WA agenda files that we use at Linaro. The change will not be
immediate. The code for supporting WA will appear in test-definitions
shortly. Please make sure you migrate to new code in case you were
using wa2-lava. There is one important note to make: we're moving to
LAVA v2. LAVA v1 (multinode) will not be supported any more. The old
code in wa2-lava will not be deleted. I will move it to 'legacy'
branch. It will be removed from master branch by the end of June 2017.
Should there be any issues with this move, please signal ASAP.
[1] https://git.linaro.org/qa/wa2-lava.git/
[2] https://git.linaro.org/qa/test-definitions.git
Best Regards,
Milosz
Hi folks,
I'm trying to run basic smoke tests on the mediatek 8173 board in the
PMWG lab. I ran into this lava-test-runner missing directory error
after the kernel was booted:
https://pmwg.validation.linaro.org/scheduler/job/1200#L4499
Any idea what would cause this?
Regards,
Lisa
Hi Neil and all,
Currently from LAVA deployment of:
Now we installed the lava-server-2017.2 and lava-dispatcher-2017.2 on a server, from the system can use:
lava lava-dashboard-tool lava-dispatcher-slave lava-mount-masterfs lava-slave
lava-daemon lava-dispatch lava-master lava-publisher lava-tool
My question is:
1. How to use those command under linux to let it works as the picture shows ?
2. We try to use $lava-master, the log shows following error, seems the lava-server can't run as a sub-process, since from the git lava-server package there is no lava-server executive command installed, can you help it ?
File "/usr/local/bin/lava-master", line 4, in <module>
__import__('pkg_resources').run_script('lava-server==2017.2', 'lava-master')
File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 738, in run_script
File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 1499, in run_script
File "/usr/local/lib/python2.7/site-packages/lava_server-2017.2-py2.7.egg/EGG-INFO/scripts/lava-master", line 39, in <module>
main()
File "/usr/local/lib/python2.7/site-packages/lava_server-2017.2-py2.7.egg/EGG-INFO/scripts/lava-master", line 36, in main
return daemonise(PIDFILE, LOGFILE)
File "/usr/local/lib/python2.7/site-packages/lava_server-2017.2-py2.7.egg/lava_server/daemonise.py", line 97, in daemonise
child = Popen(args)
File "/usr/local/lib/python2.7/subprocess.py", line 711, in __init__
errread, errwrite)
File "/usr/local/lib/python2.7/subprocess.py", line 1343, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
Thanks & Best Regards !
Hi,
May I know how DUT communicate with Worker?
How DUT test results back to Worker?
From the web pages knows the serial port and TCP port, if in DUT there is no software for the test result back to Worker, then how it works?
Thanks & Best Regards!
Hi,
Currently after the install of lava-master and lava-slave, how can I get the usage such as following:
$ ls --help
Usage: ls [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuvSUX nor --sort is specified.
Mandatory arguments to long options are mandatory for short options too.
-a, --all do not ignore entries starting with .
-A, --almost-all do not list implied . and ..
--author with -l, print the author of each file
......
$lava-slave --help
Traceback (most recent call last):
File "/usr/local/bin/lava-slave", line 4, in <module>
__import__('pkg_resources').run_script('lava-dispatcher==0.0.0', 'lava-slave')
......
Thanks & Best Regards
Hi Neil/guys
thanks for the update. In your presentation you talk about pre-requisites
for the V2 migration and one of them is "Make all devices on all instances
usable with V2". When will this happen for Juno, HiKey and X15?
I'm guessing that LMG would need few months on top of that milestone to
migrate our test jobs, re-establish dashboards/trends, setup pre-merge
testing, etc before step #1 (lava-dispatcher will *disable* V1 submissions
entirely) happens.
On 14 December 2016 at 17:03, Neil Williams <neil.williams(a)linaro.org>
wrote:
> Everyone using LAVA should be aware of V1 and V2 and that V1 is going
> to be turned off. The plan for how to do that has been discussed
> within the team and within Linaro. The most recent presentation on the
> migration can be seen here:
>
> http://connect.linaro.org/resource/las16/las16-503/
> (Note: the video will auto-start, be aware.)
>
> The slides are available on slideshare:
>
> http://www.slideshare.net/linaroorg/las16503-lava-v2-migration
>
> The dates for each step in the migration are not finalised but will
> occur during 2017, this is advance notice.
>
> The highlights of the migration are:
>
> 0: During 2017, regular announcements will be made on this list before
> each major change. In addition, the regular release announcements will
> include details of the major changes in that release.
>
> 1: The first major change will be that a new release of lava-server
> and lava-dispatcher will *disable* V1 submissions entirely. Any queued
> V1 test jobs will become invalid upon this upgrade,
>
> 2: A later release will remove V1 documentation and start removing the
> V1 source code.
>
> 3: A release will be made which *forcibly deletes V1 test jobs,
> bundles, filters and image reports*. This is required to complete the
> removal of the V1 source code.
>
> 4: The final step of the migration is a release containing no V1
> source code at all. Only V2 support will remain. This is essential as
> the V1 source code is currently blocking some useful additions to V2
> as well as plans for future development. The data cannot remain
> accessible without the V1 source code. There is not and can not be any
> support for converting V1 data to V2.
>
> Please take this chance to read up on the V2 documentation, including
> how Results, Queries and Charts replace the deprecated V1 support from
> filters and image reports.
>
> Work has started upstream on making sure the migration runs smoothly,
> especially when deleting large numbers of V1 test cases.
>
> Remember: Once the first major step is released, upgrades will stop
> running any V1 test jobs. Subsequent releases will include changes
> which force the deletion of your V1 test data.
>
> If you want to preserve your V1 data, consider setting up a read-only
> reference instance which is then pinned at a particular release of
> LAVA to prevent deletion of the V1 data.
>
> --
>
> Neil Williams
> =============
> neil.williams(a)linaro.org
> http://www.linux.codehelp.co.uk/
> _______________________________________________
> Lava-announce mailing list
> Lava-announce(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lava-announce
>
--
With best regards,
Jakub Pavelek
Linaro Mobile Group project manager
Linaro.org│Open source software for ARM SoCs
Hi,
Chase did an excellent job and put together a piece of code that
allows us local execution of lava-test-shell. This means we can use
our 'lava' test definitions on the boards that are not deployed in any
LAB. There are 2 main reasons for doing that:
- prototyping tests for LAVA
- semi-automated execution of tests on targets that are not deployed in any LAB
Major part of this code is taken directly from lava dispatcher. There
are slight modifications but I would like to keep them to minimum or
remove at all (if possible). So the question follows - is there a way
to achieve the same goal with only LAVA code? One of the biggest
problems was requirement for ACKing that lava-test-shell requires.
This makes the tests 'interactive' which isn't best for semi-automated
execution. This bit was removed and now we're able to use test shell
locally in non-interactive mode. The README file describes the use
cases we're covering. Any comments are welcome. Code can be found
here:
https://git.linaro.org/qa/lava-local-test.git
milosz
Hi,
I'm having issues trying to set up a test that is multinode with lxc workers.
I end up with a test that fails with:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/lava_scheduler_app/dbutils.py", line 808, in select_device
pipeline_job.pipeline.validate_actions()
File "/usr/lib/python2.7/dist-packages/lava_dispatcher/pipeline/action.py", line 238, in validate_actions
raise JobError("Invalid job data: %s\n" % self.errors)
JobError: Invalid job data: ['Invalid job - missing protocol']
I have tried setting the lava-lxc protocol in a way that works with single node tests, but it doesn't seem to be there in the job for this specific node. Is there something I am missing with how to supply the lxc protocol for a role when using multinode?
Thanks,
Nick Huber
Hi,
I'm having issues where the test shell works and then it doesn't, even after resubmit of the same job that worked. In the Boot action, after the export PS1 = \"lava-test: # \" I get ". None" and stays there. Then tries to go to the lava-test-shell and hangs waiting for a prompt until it times out.
Any suggestions on this issue?
Below are the boot and test section logs:
- Boot: pastebin.ubuntu.com/23063162/
- Test: pastebin.ubuntu.com/23063161/
I will appreciate a response.
Thanks,
Josue
Hi,
Has anyone tried to set up a LAVA instance where another test management system invokes this instance just for test execution and return the results to the other test system?
In other words, using LAVA as a Test Execution Engine. Any pointers?
Thanks,
Josue
