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.
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?
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.