Bug 1100593 - [RFE] Conditional reservation support for harness independent reservation
Summary: [RFE] Conditional reservation support for harness independent reservation
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Beaker
Classification: Community
Component: scheduler   
(Show other bugs)
Version: develop
Hardware: All
OS: Linux
high
medium vote
Target Milestone: 24.0
Assignee: Dan Callaghan
QA Contact: tools-bugs
URL:
Whiteboard: Misc
Keywords: FutureFeature, Patch
Depends On: 639938
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-23 07:42 UTC by Amit Saha
Modified: 2018-02-06 00:41 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 639938
Environment:
Last Closed: 2017-02-21 18:50:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Amit Saha 2014-05-23 07:42:53 UTC
+++ 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:

Comment 2 Nick Coghlan 2014-07-21 06:04:59 UTC
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.

Comment 3 Dan Callaghan 2014-07-24 02:40:42 UTC
(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).

Comment 5 Roman Joost 2016-09-16 00:02:09 UTC
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.

Comment 6 Dan Callaghan 2016-10-18 01:47:24 UTC
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

Comment 10 Dan Callaghan 2017-02-21 18:50:15 UTC
Beaker 24.0 has been released.


Note You need to log in before you can comment on or make changes to this bug.