[Beaker-devel] API design for harness independent system reservations

Nick Coghlan ncoghlan at redhat.com
Thu May 15 09:27:53 UTC 2014


On 05/15/2014 05:01 PM, Amit Saha wrote:
> 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

I see four problems with that:

1. You may not care about warnings
2. If you're only interested in cases where the test hangs, you may not
care about failures
3. "Fail" already means something else, so you'd have to introduce a new
word like "Error" and explain what it means
4. Reserve "only if it passes" doesn't make much sense (and suggests
you're using Beaker for something where OpenStack might be a better fit)

> We don't need a "never" (just don't add a "reservesys" element to the XML).

Yes, that can just be a NULL in the DB, and None in Python.

> 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.

I picked those three levels because they're the ones that seem useful:

- reserve on installation failure/crash/infinite loop/deadlock/kernel
panic/etc (as indicated by EWD Abort)
- reserve on actual error (as indicated by EWD Abort or Fail result)
- reserve on dubious behaviour (as indicated by EWD Abort, Fail result
or Warn result)

Now, you could come up with new names for them, but "onabort", "onfail",
"onwarn" cover it without introducing any new concepts other than
"onwarn implies onfail which in turn implies onabort".

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane

Testing Solutions Team Lead


More information about the Beaker-devel mailing list