1) Change submit results to not be an action.
So it would be implicit that we always want to submit results? I know there are times that we do jobs that do not submit results.  For instance, when testing the scheduler, or other pieces of LAVA.  Also, where would the results be submitted from? Still from the dispatcher?  There's an unrelated issue we've discussed before with submitting results to streams that must be authenticated to.  One of the earlier options that came up for this was submitting results from the scheduler, however I'm not sure I like that any better.
 
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.
Those would be parameters to the action? The way it works right now is that we have a default location where all the test results go, and then they are gathered at the end.  I'm not sure I understand how this helps to let the job submitter specify the location.
 
3) Change the lava-test and lava-android-test to store into
  result_locations and the submit step to read from there.
See #2, we already do this I believe, we just don't give an option to change that location at runtime.  This location is _inside_ the image because thats where the parsing takes place.  I'm starting to wonder if you want it to be stored outside the image for qemu testing purposes?  Since lava-test is the piece that parses it, it needs to be inside the image, but with lava-android-test it could certainly be outside.
 
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.
Maybe if you showed how this might look in json it would make sense to me.  I don't think we should be too restrictive with how it's used though.  One thing that's come up before as a possible user of this is to have outputs that come out of some actions used in other actions.  For instance, if we had a build_foo action that you pointed at a source tree and produced output, how could you point a subsequent step at the artifacts of that build for consumption?

Thanks,
Paul Larson