On Fri, 11 Nov 2011 16:15:47 +0800, yong qin <yongqin....@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, > lava-scheduler), > 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. Cheers, mwh _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
