| Summary: | RFE: indication of expected duration of queued job state | ||
|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Andy Grover <agrover> |
| Component: | web UI | Assignee: | beaker-dev-list |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | medium | ||
| Version: | 0.9 | CC: | atodorov, azelinka, bpeck, mastyk, stl, tools-bugs |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | Measurements | ||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-06-02 11:49:02 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Andy Grover
2012-04-19 17:39:54 UTC
This is a lot harder than you think. Because of groups, loans, ownership. Everyone has access to different systems. But I do think its worth trying. It just may not be super accurate at first. Yeah the number we would be trying to track is a real moving target. This request has been made a few times before, and put into the "It doesn't really work like that" basket. If we can't do it somewhat accurately I don't see the point in it at all. All we would be doing is spreading misinformation, which is surely worse then no information. I wonder if we should put our effort into optimising our queueing algorithm first as it may change how we calculate this ETA number anyway. Perhaps a reasonable intermediate step would be just a more general information on the current beaker load, perhaps by arch or something. So then if someone has a lot of s390x jobs waiting for sometime, they could rest assured by going to a page that displays a somewhat vague coloured rendition (think colour coded USA terror alerts) of the current state of things in beaker. This may even avoid emails to admins with the "Why is my job taking so long" subject. ncoghlan: I don't think we can realistically provide this, as there are too many variables to come up with a good estimate (if your job can run on a dynamic VM, you're likely to have a much shorter queue time than if you need a rare piece of hardware). We might be able to offer a variant on FR-6 that included a "place in queue" for a particular recipe, but this is still a fairly tricky UX problem, so I'm wary of comitting to anything specific until we see how FR-1 to FR-9 shape up. FR-6: Current Load per Architecture FR-1: Server Load FR-9: Speed of service Bumping out of 0.11, based on ncoghlan's input as above. *** Bug 1071372 has been marked as a duplicate of this bug. *** Hello, thank you for opening issue in Beaker project. This issue was marked with component "web ui". As we are not planning to address any further issues in current UI, due to technical stack and not being able to work with Python 3 codebase, I'm closing this issue as WONTFIX. New UI will be reimplemented within new versions of Beaker. If you have any questions feel free to reach out to me. Best regards, Martin <martin.styk> |