[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