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 <dcall...@redhat.com> Software Engineer, Infrastructure Engineering and Development Red Hat, Inc.
signature.asc
Description: PGP signature
_______________________________________________ Beaker-devel mailing list Beaker-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
