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

Nick Coghlan ncoghlan at redhat.com
Thu May 15 06:30:34 UTC 2014


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?

My contention is that the "simple" meanings for "onfail" and "onwarn"
are actually useless from an end user perspective, and the "implied or"
approach is far more useful.

>From a docs perspective, explaining it in terms of implications rather
than "ordering" may be clearer. So:

- never
- onabort
- onfail (implies onabort)
- onwarn (implies onfail and onabort)
- always

And then the individual meanings are still:

 - never =  never reserve system
 - onabort = reserve system if the recipe status is Abort
 - onfail = reserve system if the recipe status is Complete and the
recipe result is Fail
 - onwarn = reserve system if the recipe status is Complete and the
recipe result is Warn
 - always = reserve system if the recipe status is Abort or Complete

>From an implementation perspective, those checks then become something like:

    def should_reserve(status, result, when):
        # check the recipe is actually finished
        if status not in (Abort, Complete):
            return False

        # check the status and result independent options
        if when == ReserveAlways:
            return True
        if when == ReserveNever:
            return False

        # check for an aborted recipe
        # onfail and onwarn both imply onabort
        if status == Abort:
            return True
        if when == ReserveOnAbort:
            return False

        # check for a failed recipe
        # onwarn implies onfail
        if result == Fail:
            return True
        if when == ReserveOnFail:
            return False

        # only thing left to do is check for a warning
        assert when == ReserveOnWarn
        return result == Warn

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