Hi all! 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. 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.
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. 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? Thanks! Mirsad
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
