error handling and reporting in the dispatcher

Paul Larson paul.larson at
Thu Nov 10 22:48:47 UTC 2011

On Thu, Nov 10, 2011 at 4:46 PM, Paul Larson <paul.larson at> wrote:

> On Thu, Nov 10, 2011 at 4:32 PM, Michael Hudson-Doyle <
> michael.hudson at> wrote:
> ...
>> After all this thinking and typing I think I've come to some
>> conclusions:
>> 1) There is a category of error where we should just stop.  As far as I
>>   know, this isn't really handled today.
>> 2) There is another category of error where we should report failure,
>>   but not execute any other actions.  This makes me thing that having
>>   'report results' as an action is a bit strange -- perhaps the
>>   dashboard and bundle stream should really be directly in the job,
>>   rather than an action?
>> ISTR we defined some exceptions in lava as being Fatal, or Non-Fatal -
> the idea being that there would be subclasses of those to add detail.  That
> way we don't need to decide on every single error, just how far to pass it
> up before someone can take action on it.  The fatal ones of course would be
> the ones where we just can't reasonably expect to proceed and gain anything
> from it (ex. image fails to deploy).
>> 3) I need to write another, probably equally long, email about
>>   dependencies between actions :-)
> Ah yes, we spoke a bit about that recently.  I'd love to hear your ideas
> on it.
I guess I forgot to add some things to the previous email... I'm mainly
interested in 2 things when it comes to any of these errors:
1. highlighting them in a way that makes it easy for us to find out when
something goes wrong.
I think some of this, perhaps, goes along with another conversation about
parsing the serial log and splitting it up into sections.

2. capturing the full backtrace (we're better about this now I think, I
have had much less frustration with this lately)

Paul Larson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the linaro-dev mailing list