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

Amit Saha asaha at redhat.com
Wed May 14 22:35:39 UTC 2014



----- Original Message -----
> From: "Nick Coghlan" <ncoghlan at redhat.com>
> To: beaker-devel at lists.fedorahosted.org
> Sent: Wednesday, May 14, 2014 6:04:28 PM
> Subject: Re: [Beaker-devel] API design for harness independent system	reservations
> 
> 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

My confusion was mainly rooted in the ordering idea that you proposed. If we were to consider each
state either on it's own (first implementation) or a combination (second implementation),
it is less confusing as far as I see it. The first implementation is not powerful enough.
The second implementation allows dubious combinations which may not have a meaning - we would then 
just have to trust the submitter to do the right thing. 

However, if we were to implement the ordering, "onfail" also including "onabort" muddies things, for example. 
"always" is an exception, since it just means always, really and so is "never". But having a ordering between
"onabort", "onfail" and "onwarn" is what I am not very clear about.



More information about the Beaker-devel mailing list