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

Nick Coghlan ncoghlan at redhat.com
Wed May 14 08:04:28 UTC 2014


On 05/14/2014 04:06 PM, Nick Coghlan wrote:
> New proposal
> ============
> 
> - go back to Amit's enum idea, but make it an *ordered* list.
> - under this model, we'd have the following enum options:
>   * never
>   * onabort
>   * onfail
>   * onwarn
>   * always
> - each level would implicitly include the levels above, so if you say
>   "onwarn", it will also reserve the system for failures and aborts,
>   and "onfail" will also reserve the system for aborts

Amit pointed out this list can be seen as a little odd, since it blurs
the difference between the recipe status and the recipe result. It's
really the amalgamation of two different lists into one.

First list (based on recipe status):

    * never
    * onabort
    * oncompleted

Second list (based on recipe result, only applies when status is Completed):

    * onfail
    * onwarn
    * onpass

These combine into a single list by replacing the single "oncompleted"
entry with the three recipe results of interest:

    * never
    * onabort
    * oncompleted_fail
    * oncompleted_warn
    * oncompleted_pass

And then my latest proposal simplifies the names to omit the implied
"completed" status from the last 3 entries, and make it explicit that
the final option covers every possible outcome of running a recipe by
referring to it as "always" rather than "onpass":

    * never
    * onabort
    * onfail
    * onwarn
    * always

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