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

Matt Jia mjia at redhat.com
Wed May 14 23:33:38 UTC 2014



----- Original Message -----
From: "Amit Saha" <asaha at redhat.com>
To: "Beaker development" <beaker-devel at lists.fedorahosted.org>
Sent: Thursday, May 15, 2014 8:35:39 AM
Subject: Re: [Beaker-devel] API design for harness independent	system	reservations



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

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
 - always = reserve system in regardless of the recipe status and result

_______________________________________________
Beaker-devel mailing list
Beaker-devel at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel


More information about the Beaker-devel mailing list