On Mon, 14 Nov 2011 13:17:25 -0600, Paul Larson wrote:
> > 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 p
> 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? S
On Fri, 11 Nov 2011 16:15:47 +0800, yong qin 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_linar
>
> 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
Recently I've been thinking about the dispatcher a bit (as other mails
should have indicated) and I've gotten to think about dependencies
between actions. If you don't already know, a dispatcher job file
mostly consists of a list of actions to execute, for example:
"actions": [
{
"com
