On 16 February 2011 05:27, Zygmunt Krynicki <zygmunt.kryni...@linaro.org>wrote:
> W dniu 16.02.2011 11:22, Mirsad Vojnikovic pisze: > > > > 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. >> > > Hi Mirsad. > > I must have missed this part of your email, sorry for responding so late. > My intention was not to expose the dispatcher for farm users but for generic > higher-level abrek replacement. > OK, then I understand better. > In this case one could develop and experiment with jobs using their > favorite text editor and a command line tool that effectively dispatches a > job on a locally connected device (android or "classic" board). This would > allow us to write custom code that is not yet in the released LAVA stack > that can interact with a new class of device properly, like in our case, > android. Totally agree with you, this is a valid user scenario where direct control is needed. 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? > I think this can wait until we 1) have resources that can be committed to do > this 2) agree on what to do with android+abrek+lava in general. > OK, sounds reasonable. Best regards > ZK >
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
