On 02/22/2013 11:14 AM, Dan Callaghan wrote:
And I just noticed, rhts-abort actually allows the task to abort the
whole recipe set or even the whole job too. I suppose it makes sense to
allow it (at least the recipe set), if the task really knows that the
whole recipe set is busted. So I should probably add something for that,
although it doesn't fit in well with the current proposal, which
considers the recipe to be the top level...
I think it's good to stick with that model for the stable API.
Aborting just the task is already covered through updating the task
status, adding:
POST /recipes/(recipe_id)/abort
seems reasonable enough as a way to mark all the incomplete tasks as
aborted in a single operation.
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.
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.
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)