Sorry, I messed up the comments. I clean it up here.
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel
_______________________________________________
Beaker-devel mailing list
Beaker-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/beaker-devel