Bug 1856351
| Summary: | Build page should show metrics for when the build ran, not the last 30 minutes | ||||||
|---|---|---|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Paul Weil <pweil> | ||||
| Component: | Management Console | Assignee: | Jon Jackson <jonjacks> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Yadan Pei <yapei> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 4.5 | CC: | aos-bugs, jokerman, spadgett, yapei | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 4.7.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: |
Cause: All resource utilization charts show the last hour by default.
Consequence: Builds that ran more than an hour ago would show empty charts.
Fix: Adjust the utilization charts timespan to account for the start and end time of a build.
Result: Utilization charts on build details pages now show data for the time that the build ran.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2021-02-24 15:13:57 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: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Paul Weil
2020-07-13 12:57:35 UTC
Will address next sprint. I haven't looked into a fix for this yet, but I know one issue we will have is that we only display the time on the x-axis of our utilization area charts. So if a build was not run 'today' or spans across multiple dates, the times displayed on the chart might be misleading. Since these charts are pretty compact, adding a date to the x-axis might be tricky, so we might need some design input on this. Maybe use a relative date string below the x-axis tick marks if the date !== today? So "a day ago", "a week ago", etc. Started work on this, but clamping the time introduces a few edge cases that make this a bit more complicated than it seems. Will continue work in upcoming sprint. Haven't circled back around to this yet as other 4.6 blockers were taking priority. I should be able to look at this next sprint. PR pending Created attachment 1726169 [details]
Build details charts when build ran one hour ago
CPU Usage charts still show 'No datapoints found.' assigning back for confirmation let me know if the issue in comment 8 needs to be tracked in separate bug (In reply to Yadan Pei from comment #8) > CPU Usage charts still show 'No datapoints found.' assigning back for > confirmation I think this should probably be tracked as a separate bug. I'd have to look further into why we aren't getting any data for CPU usage in some cases, but I don't think it's is related to the original bug. Our prometheus query time span is correct, as can be seen by the data on the other charts. The same start time and time span values are used for all charts on this page, so we are definitely querying CPU usage for the same timespan as the other utilization charts. I can think of 3 possibilities off the top of my head: 1. There is a problem with the CPU usage query 2. There is an edge case we aren't considering 3. Prometheus is legitimately returning no data for CPU usage in some cases. My guess is the third case. Some of the builds I tested only ran for a few seconds, and probably were not CPU intensive, so I'm thinking that CPU usage was so miniscule that Prometheus doesn't return any data. When build runs one hour ago, the build charts are still visible on build details. And we show hour:minutes:seconds when build duration is short. The original issue is fixed, will open separate bug for comment 8 Verified on 4.7.0-0.nightly-2020-11-09-235738 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2020:5633 |