2011/2/16 Mirsad Vojnikovic <mirsad.vojniko...@linaro.org>: > Hi all! >
hi Mirsad, > This is very good analysis you have done, and I would just add that Monkey > is only one simpler example where the test execution using abrek is not an > option. True. > Another example from Android world is CTS: > http://source.android.com/compatibility/cts-intro.html. Most certainly, all > test suites and frameworks are not only DUT-based. Some of them have more or > less dependencies and functions on the PC side as well. > Yes, in fact, Android CTS replies on PC side, too. The device will try to reset adb (through USB gadget) for several times in order to probe the compatibility to host (Windows/Linux/MacOSX). > Zygmunt has already identified key points for Job Dispatcher to support > this, but one thing I would like to comment: > >> Another crazy option would be to expose LAVA Job Dispatcher directly and >> allow people to run jobs. In this case one job would use abrek and some >> other tools to invoke tests, process results and send them to the dashboard >> while other job (one for android) would not run abrek at all, instead it >> would call some other helper, while still reusing identical components for >> "process results and send to result storage" phases. This is still in flux >> but has some advantages: >> 0) Jobs are simple text files that can be stored and shared with others >> 1) Jobs can encapsulate device information like which android device to >> connect to and how. >> 2) Jobs can still "call" to other parts of the LAVA stack such as result >> submission >> 3) Jobs can be extended locally (by LAVA plugins) so that anyone can >> develop specialized use cases for their very specific needs without >> altering the stack or having to write something completely custom. > > I think exposing Job Dispatcher directly would not be a good idea for > validation farm, where test jobs are queued for execution via Scheduler (see > LAVA architecture). Bypassing the job queue on the Dispatcher level should > only be allowed in exceptional cases, i.e. canceling jobs for server/board > update or similar. There might be scenarios where the unrestricted direct > control is desirable, but that should be only allowed for local development > environments. > Thanks for pointing out this. > It would be good to have this specified/discussed somewhere already now, > maybe in the Dispatcher blueprint, or maybe we need additional blueprint or > wiki spec for it? Yes, it would be great. Cheers, Jim Huang (jserv) http://0xlab.org/ _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
