+++ This bug was initially created as a clone of Bug #639938 +++ Description of problem: Bug 639938 implements an initial version of support for harness independent system reservation. If a recipe has <reservesys> element in it, the system is reserved after the tests are completed, else not. However, there is no way to specify any other criteria *when* to reserve the system. Some discussion on this can be found here: https://lists.fedorahosted.org/pipermail/beaker-devel/2014-May/000999.html Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Actual results: Expected results: See Description Additional info:
Summarising the open questions that resulted in this being delayed: A recipe actually has three levels of "something went wrong": - Aborted (external watchdog timeout, kernel panic, installer dropped into interactive mode) - Failed (recipe completed, at least one task reported a failure) - Warn (recipe completed, no tasks failed, but at least one reported a warning) The simplest option would be a single boolean flag like "skipifpass=True" - if the recipes passes, no reservation would occur, if it aborted, failed, or there was a warning, it would automatically get reserved. This approach would avoid the complexities discussed in the email Amit linked, and likely deliver most of the value of the feature - "pass vs not pass" is likely to be the most interesting distinction, and a single flag would be vastly simpler to implement and test.
(In reply to Nick Coghlan from comment #2) > The simplest option would be a single boolean flag like "skipifpass=True" - > if the recipes passes, no reservation would occur, if it aborted, failed, or > there was a warning, it would automatically get reserved. > > This approach would avoid the complexities discussed in the email Amit > linked, and likely deliver most of the value of the feature - "pass vs not > pass" is likely to be the most interesting distinction, and a single flag > would be vastly simpler to implement and test. This also matches the existing option we have for /distribution/reservesys: RESERVE_IF_FAIL (which, despite its name, reserves when the result is anything other than Pass).
We've had a quick meeting about this today and basically settled on what was described in Nick's mail as the new proposal: * use an enumeration with a default * for backwards compatibility we'll support: * case the element is not supplied treat it as: <reservesys when="never" /> * if the element is supplied treat it as: <reservesys when="always" /> I'm bumping this priority since with Bug 1369431 it seems more people will benefit from supporting this while the implementation shouldn't be that tricky.
http://gerrit.beaker-project.org/5323 keep the default reservesys duration in only one place http://gerrit.beaker-project.org/5324 db structure and XML support for conditional reservation http://gerrit.beaker-project.org/5325 tests: simplify TestUpdateStatusReserved a little bit http://gerrit.beaker-project.org/5326 scheduler support for conditional reservations http://gerrit.beaker-project.org/5327 HTTP API for updating conditional reservations http://gerrit.beaker-project.org/5328 UI for updating conditional reservations
Beaker 24.0 has been released.