If you don't follow dispatcher commit or review mail, you might not be
aware than Andy and I have been working an implementation of the "black
box" tests we've been talking about for a while. This mail is just a
summary of the things that have been mentioned in review that would be
good to fix "in the next branch" so that we don't forget about them.
The list probably doesn't make a great deal of sense if you haven't read
the review mail, sorry about that.
In no particular order:
* explode if an android test has deps rather than trying to install
via apt-get
* need to have lava-test-runner be a proper service on android
* make power_off() == 'in the master image' consistently
* make cmd_android_install_binaries work for !master deployments
* think about suppressing the root shell on console on ubuntu
* remove separation between LavaClient and TargetBasedClient,
consider slimming (and renaming?) interface
* fix retreive_results return interface
* rename download_image
* look at how boot_options works
* define common target superclass for FastModelTarget and QEMUTarget
* set up automated dispatcher validation
I've just thought of one more thing, which is that running a
lava_test_shell action followed by a lava_test_run action in the same
job will likely not work well because the lava test shell test will be
run again when the lava_test_run action boots the image -- maybe the
lava-test-runner should clean up after itself so that the tests only run
on *the* next boot rather than every following boot? If we do do the
"disable auto-login-shell" action, then it should probably reenable that
too...
Cheers,
mwh
Hi again all,
Zen are still running tests and now I have to run more tests from our side. Because I'm off site tomorrow this won't happen until Wednesday. I'll keep you posted.
Thanks
Dave
Sent from my Aldis Lamp
Hi,
I've forgotten the status of this. We want to be able to do ad-hoc
testing of lava branches on a 'dogfood' server. "ssh dogfood" works in
the lab but the resulting instance does not appear to have LAVA
installed on it. Is this just waiting to be set up?
IIRC, the goal was not to have this host accessible from the internet,
rather we would use ssh port forwarding so we could point our local
browser at the remote hosts. In this case, there is not much point in
having dogfood.validation.linaro.org set up in the DNS (as there
currently is...).
If this is just stalled for lack of time, I can finish setting up the
instance.
Cheers,
mwh
