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.

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.


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.

Best regards
ZK

_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Reply via email to