It occurred to me today that with the server side reservation system added in 0.17, that actually becomes something that could be made configurable for a previously submitted recipe.
The kinds of cases where that seemed potentially interesting to me were:
* After manually kicking a recipe that stalled for some reason (the case that prompted the idea) * After noticing something odd in the execution of a long running recipe * Switching from "always" to "only on failure" if you forget to make it conditional (or vice-versa) * Adding or removing the reservation request if simply made a mistake at submission time
There'd be a bit fiddling involved - new CLI commands to manage it, new web UI elements on the job details page.
If we did it at all, perhaps it would be best left until after the results page redesign?
Cheers, Nick.
Excerpts from Nick Coghlan's message of 2014-11-10 15:27 +10:00:
It occurred to me today that with the server side reservation system added in 0.17, that actually becomes something that could be made configurable for a previously submitted recipe.
The kinds of cases where that seemed potentially interesting to me were:
- After manually kicking a recipe that stalled for some reason (the case
that prompted the idea)
- After noticing something odd in the execution of a long running recipe
- Switching from "always" to "only on failure" if you forget to make it
conditional (or vice-versa)
- Adding or removing the reservation request if simply made a mistake at
submission time
Yes, this sounds quite useful. These are all common use cases.
There'd be a bit fiddling involved - new CLI commands to manage it, new web UI elements on the job details page.
If we did it at all, perhaps it would be best left until after the results page redesign?
Yes that would be the best time to add it -- during or after.
From: "Dan Callaghan" dcallagh@redhat.com
There'd be a bit fiddling involved - new CLI commands to manage it, new web UI elements on the job details page.
If we did it at all, perhaps it would be best left until after the results page redesign?
Yes that would be the best time to add it -- during or after.
Redesigning the results page sounds like a potentially promising focus for Beaker 20, then. There are several outstanding issues like fleshing out the restraint integration, stabilising the Project Atomic support and improving inventory scanning that can be worked on as Beaker 19.x releases, while putting together a concrete proposal for the result reporting enhancements in Beaker 20 early next year.
We could also scope out the Fedora infrastructure integration requirements for possible inclusion in Beaker 20 - that should probably be captured as its own design proposal, so Tim, Kevin, et al can review it relatively easily.
Cheers, Nick.
On 11/11/2014 07:58 AM, Dan Callaghan wrote:
Excerpts from Nick Coghlan's message of 2014-11-10 15:27 +10:00:
It occurred to me today that with the server side reservation system added in 0.17, that actually becomes something that could be made configurable for a previously submitted recipe.
The kinds of cases where that seemed potentially interesting to me were:
- After manually kicking a recipe that stalled for some reason (the case
that prompted the idea)
- After noticing something odd in the execution of a long running recipe
- Switching from "always" to "only on failure" if you forget to make it
conditional (or vice-versa)
- Adding or removing the reservation request if simply made a mistake at
submission time
Yes, this sounds quite useful. These are all common use cases.
There'd be a bit fiddling involved - new CLI commands to manage it, new web UI elements on the job details page.
If we did it at all, perhaps it would be best left until after the results page redesign?
Yes that would be the best time to add it -- during or after.
RFE filed as https://bugzilla.redhat.com/show_bug.cgi?id=1162500
Cheers, Nick.
beaker-devel@lists.fedorahosted.org
-
Dan Callaghan -
Nick Coghlan