Zach/Vishal,
During our meeting today we spoke a little about improving CTS in LAVA.
One issue sounds like CTS reboots the target and due to our master-image
uboot commands the device doesn't boot back into Android.
I thought I'd give you pointer on how that could be improved in LAVA:
<http://bazaar.launchpad.net/~linaro-validation/lava-dispatcher/trunk/view/h…>
I think you might be able to somehow doctor that DrainConsole thread to
search for uboot prompts and if hit, run the android boot-cmds to get it
set back up.
Hope it helps once somebody starts investigating,
-andy
Hi all !
I follow the document:
http://lava-deployment-tool.readthedocs.org/en/latest/index.html#limited-de…
to deploy lava instance.
Finally I want to install the "demo" extension in LAVA-Server source-tree,
but I am not really understand what means of this document,
and the extension not work in my LAVA-Server actually
so I put on my config file as below, anyone could help me to check them?
1. /srv/lava/instances/limited/code/custom.cfg ==>
http://paste.ubuntu.com/1619181/
2. /srv/lava/instances/limited/instance.conf ===>
http://paste.ubuntu.com/1619188/
Thank you very much .
Hi all,
I have already read the official document about how to write a LAVA server
extension:
http://lava-server.readthedocs.org/en/latest/extending.html
We can find above example in lava-server source-tree,
and I want to install the example extension from lava-server source-tree
directly,
my steps as below :
* instance name = testinstance
1. Get LAVA server source-tree
$ bzr branch lp:lava-server
2. Go to "demo" directory
$ cd lava-server/demo/
3. Active instance ven
$ . /srv/lava/instances/testinstance/bin/activate
4. Install the extension
$ ./setup.py develop
5. Patch setup.py and install again
refer: https://bugs.launchpad.net/lava-server/+bug/1116560
$ ./setup.py develop
output: http://paste.ubuntu.com/1615747/
6. Restart LAVA service
$ sudo restart lava-instance LAVA_INSTANCE=testinstance
output: lava-instance (testinstance) start/running
Everything look fine !
Finally go to Django "Site administration" ... ... nothing changed!
Screenshut:
https://picasaweb.google.com/113942492163843349547/201326?authuser=0&feat=d…
Any idea, thank you !
Hey Guys,
I've just proposed merging:
https://code.launchpad.net/~doanac/lava-lab/lava-scripts/+merge/146547
I suspect this may need a couple of rounds of feedback. However, its a
pretty exciting changeset. In the end, you can run some very simple
commands like:
# creates a new worker node instance called "staging" on
# minion(lava-test) minion-ip(192.168.0.145)
./lava-add-worker lava-test 192.168.0.145 staging
# upgrade a lava deployment. this will:
# - shutdown all worker node instances
# - upgrade the master instance
# - upgrade all worker nodes
# - bring all worker nodes back online
./lava-upgrade production
It needs more testing, but I wanted to get some early input before
spending any more time on it.
Hi, Andy Doan & Paul Sokolovsky & Vishal Bhoj & All
Now lava-test-shell is supported by LAVA,
and android team is considering adding the support on android-build.
I want to add following 3 interfaces on the android-build,
*1. lava-test-shell-url(url=
http://cbuild.validation.linaro.org:80/helpers/scheduler/lava/testdef/lava-…
timeout=59400)*
where timeout is optional
when submitted, the action in job will be something like this:
{
"command": "lava_test_shell",
"parameters": {
"testdef_urls": ["
http://cbuild.validation.linaro.org:80/helpers/scheduler/lava/testdef/lava-…
"],
"timeout": 59400
}
}
*2. lava-test-shell-git(repo=git://git.linaro.org/qa/test-definitions.git
revision=master testdef=android/binder.yaml timeout=-1)
*
where revison/testdef/timeout is optional
when submitted, the action in job will be something like this:
{
"command": "lava_test_shell",
"parameters": {
"testdef_repos": [
{
"git-repo": "git://
git.linaro.org/qa/test-definitions.git",
"revision": "master",
"testdef": "android/binder.yaml"
}
],
"timeout": -1
}
}
*3. lava-test-shell-bzr(repo=lp:~terceiro/+junk/lava-dev
revision=112 timeout=-1)*
where revison/testdef/timeout is optional
when submitted, the action in job will be something like this:
{
"command": "lava_test_shell",
"parameters": {
"testdef_repos": [
{
"bzr-repo":
"lp:~terceiro/+junk/lava-dev",
"revision": "112",
"testdef": "jobs/android-busybox.yaml"
}
],
"timeout": -1
}
}
By these 3 types interface, we can do most of the things lava-test-shell
supported.
Although we can't specify the array form with one interface one time,
we can do the same things by specifying multiple times the interface of the
same type.
like *lava-test-shell-url(url=url1),**lava-test-shell-url(url=url2),*
so I think it's enough for us to use on android-build.
About this, how do you think about that?
Please feel free to give your comments. Thanks in advance!
--
Thanks,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
linaro-validation(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/pipermail/linaro-validation
Hi all,
As you know, I had to leave the office feeling every ill again yesterday. After a disturbed night, I'm feeling tired but better. I'm going to work from home on the Nexus and supporting Bernard. I'm hoping I'll be back in tomorrow.
Thanks
Dave
Sent from my Aldis Lamp
I was looking at failed health jobs last week and found something
started happening on snowballs (5 of the 7 failures):
<http://validation.linaro.org/lava-server/scheduler/reports/failures?start=-…>
lets keep an eye on this. If this continues to occur, we should probably
create a new tag just for this failure and check if there's a better
image to try for health checks.
Hi gang,
I've just deployed a long-awaited change: we can (and do) now deploy
components such as lava-dispatcher from bzr branches. If you look at
the new buildout configuration files:
http://bazaar.launchpad.net/~linaro-validation/lava-manifest/trunk/view/hea…http://bazaar.launchpad.net/~linaro-validation/lava-manifest/trunk/view/hea…
I hope it's reasonably self-explanatory what's going on: lines like
lava-dispatcher = lp:lava-dispatcher
in [branches] section says "satisify a requirement for the egg
lava-dispatcher from the branch at lp:lava-dispatcher".
Lines like
lava-dispatcher = 551
in the [revisions] section -- only present in the locked-down
buildout-production.cfg -- specify which revision to use. So when you
want to deploy a fix to production, no need to futz with pypi and tags
and post release bumps -- just push to trunk, update the revno in
buildout-production.cfg and run lava-deployment-tool update!
I hope this makes all of our lives a bit easier and let's us reduce the
time between coding a fix and getting it to our users even more.
Cheers,
mwh
