Bug 1100593
| Summary: | [RFE] Conditional reservation support for harness independent reservation | ||
|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Amit Saha <asaha> |
| Component: | scheduler | Assignee: | Dan Callaghan <dcallagh> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | tools-bugs <tools-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | develop | CC: | azelinka, bpeck, dcallagh, dkutalek, dowang, ebaak, jpazdziora, jscotka, mcsontos, mganisin, rjoost, tools-bugs, trusnak |
| Target Milestone: | 24.0 | Keywords: | FutureFeature, Patch |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | Misc | ||
| 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: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 639938 | ||
| Bug Blocks: | |||
|
Description
Amit Saha
2014-05-23 07:42:53 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. (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. |