dependencies between actions in the dispatcher
michael.hudson at linaro.org
Sun Nov 13 20:15:02 UTC 2011
On Fri, 11 Nov 2011 16:15:47 +0800, yong qin <yongqin.liu at linaro.org> wrote:
> > 1) Change submit results to not be an action.
> 2) Add a result_locations list and action_data dictionary to
> > LavaContext. My half-thought through idea is that actions will use
> > the action name as a prefix, e.g. deploy_linaro_image for a qemu
> > client might set 'deploy_linaro_image.qemu_img_path' in this dict.
> > 3) Change the lava-test and lava-android-test to store into
> > result_locations and the submit step to read from there.
> > 4) Use action data to have deploy_linaro_image and boot_linaro_image
> > (and maybe lava_test_install and lava_test_run) talk to each other.
> > about the action, from the point used by lava(lava-server,lava-dashboard,
> some actions are not necessary to specified, or to say they are certainly
> executed. like:
> 1. submit results
> if no results submitted, the test will no meaning.
> 2. deploy and boot the test target
> if not deploy and boot, then no target to test.
> 3. the installation of various test.
> if the test is not installed, we can install it before run.
> They can be or should be execute implicitly I think.
That's a good point... but sadly I don't think it works because the
actions we'd want to implicitly execute require data -- we can't
implicitly submit results without knowing where to send the results, we
can't implicitly deploy without knowing what to deploy, in the case of
out of tree tests at least, we can't know where to install a test from
before we run it.
It does seem though that we can very quickly detect all of these
problems even at submit_job time, which would be much friendlier to the
user -- but I don't instantly see how to do this without some messy hard
coding in the dispatcher.
More information about the linaro-dev