----- Original Message -----
From: "Nick Coghlan" <ncoghlan(a)redhat.com>
To: beaker-devel(a)lists.fedorahosted.org
Sent: Thursday, May 15, 2014 4:30:34 PM
Subject: Re: [Beaker-devel] API design for harness independent system reservations
On 05/15/2014 09:36 AM, Matt Jia wrote:
> I agree with amit, I donnot see any point of having a ordering between
> "onabort", "onfail" and "onwarn here.
>
> Based on my understanding, correct me if I am wrong. To determine whether
> or not the system is actually reserved
> in the relevant situations:
>
> - never = never reserve system
> - onabort = reserve system if the recipe status is onabort
> - onfail = reserve system if the recipe status is oncompleted and the
> recipe result is onfail
> - onwarn = reserve system if the recipe status is oncompleted and the
> recipe result is onwarn
So how do I express the following?:
- reserve if it fails *or* aborts
- reserve it it warns, fails *or* aborts
More importantly, what is the use case for reserving *only* if it fails,
but not if it aborts, and *only* if it warns, but not if it fails or aborts?
Okay, I think I now understand the real reason behind the ordering idea.
So, here is an idea: what if we expose only the following "When" options:
- Always
- Fail (covering "aborted" recipe state, and "failed", and
"warn" task results)
- Pass
We don't need a "never" (just don't add a "reservesys" element
to the XML).
This covers the following use cases:
- Always reserve irrespective of the task result and recipe state
- Any kind of failure
- Only when all tests pass
Unless we envision use cases which would depend on exactly the kind of failure
(warn, abort, fail), I think this is not a bad idea.