On 02/22/2013 01:27 PM, Dan Callaghan wrote:
Excerpts from Nick Coghlan's message of 2013-02-22 12:22:40
+1000:
> For higher levels, what if we considered some additional features in
> the job and recipe set XML to control how failures and abort requests
> are handled?
>
> Specifically, I'm thinking of a "cascade_aborts" attribute on jobs,
> recipe sets and recipes. If it is set, then any subcomponent being
> aborted will abort the whole thing. Recipes would also get a related
> "abortonfail" setting, where any task failing would lead to the recipe
> being aborted.
This is a nice idea, and is probably worthwhile doing...
> The choice of how to handle failures would then be in the hands of the
> person running the test, rather than being inherent in the test definition.
... but, I think that choice needs to be in the hands of the test author
*as well*. At least, RHTS thought so, since rhts-abort allows you abort
the recipe set or job.
Hmm, maybe. An alternative might be to allow "cascade_abort" to be set
on individual tasks as well as on the recipe, and for the task authors
to recommend setting that when appropriate.
And there are some situations where it makes sense. For example,
notionally /distribution/virt/install might abort the entire recipe set
if a guest failed to install (it doesn't actually, but it could). Or
a multihost test where the client detects that the server never set
itself up properly, so it aborts the whole recipe set. There are these
kinds of task failures where the task knows it is more serious than just
a failure in this task.
Although, in the reference harness we aren't planning to support
multihost anyway, so maybe for now it's enough to add the call for
aborting the whole recipe, and put the rest in Deferred Features?
Oh, good point - yes, that sounds like an excellent plan.
Cheers,
Nick.
--
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane
Python Applications Team Lead
Beaker Development Lead (
http://beaker-project.org/)
PulpDist Development Lead (
http://pulpdist.readthedocs.org)