[Beaker-devel] API design for harness independent system reservations
Amit Saha
asaha at redhat.com
Thu May 15 07:01:44 UTC 2014
----- Original Message -----
> From: "Nick Coghlan" <ncoghlan at redhat.com>
> To: beaker-devel at 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.
More information about the Beaker-devel
mailing list