Created attachment 1212211 [details] After toggling time range, CPU graph shows max=11. Reloading page gives max=550 and eliminates cropping Description of problem: Toggling back and forth between time ranges on a Pod's metrics tab leads to improper choices being made for the graph's Y-Axis. This can lead to significant cropping / illegibility. Version-Release number of selected component (if applicable): 3.3 Firefox 47 How reproducible: 100% Steps to Reproduce: 1. Start a pod and allow it to build 20 minutes of varied CPU utilization 2. Navigate to the web console's Metric tab for that pod 3. Toggle back and forth between time ranges (1 hour <-> 1 week) Actual results: The Y-axis values selected for the new time range lead to significant cropping. Expected results: The Y-axis should suit the new data set. Additional info:
Checked on OCP 3.3.1.3, the Y-axis values of all charts for memory, cpu and network have this issue after change time range from "Last week" to "Last hour". Guess that this bug should have the same root cause with bug https://bugzilla.redhat.com/show_bug.cgi?id=1386820
Created attachment 1212489 [details] cpu/memory-issue
https://github.com/openshift/origin-web-console/pull/707
*** Bug 1386820 has been marked as a duplicate of this bug. ***
This has been merged into ose and is in OSE v3.4.0.16 or newer.
Will continue to verify the this bug after bug 1388833 fixed.
Checked on OCP v3.4.0.18. After switch between time range, Y-axis values could scale accordingly, but it took too much time during the chart and value updating accordingly, user had to wait for at least 15 seconds or event longer. Assign it back, pls help to check again.
(In reply to Yanping Zhang from comment #8) > Checked on OCP v3.4.0.18. After switch between time range, Y-axis values > could scale accordingly, but it took too much time during the chart and > value updating accordingly, user had to wait for at least 15 seconds or > event longer. Assign it back, pls help to check again. Hi, Yanping. If I understand, the chart did not update at all for at least 15 seconds? If so, it sounds like a different performance problem. Does this happen every time or only once? If you can reproduce, please check the events for the openshift-infra namespace and the logs for the hawkular-metrics pod. I suggest we open a separate bug to track.
(In reply to Samuel Padgett from comment #9) > Hi, Yanping. If I understand, the chart did not update at all for at least > 15 seconds? If so, it sounds like a different performance problem. When switch time range, the original chart disappears, only X-axis and Y-axis left, and new chart will show up after wait for about 15 seconds. > Does this happen every time or only once? If you can reproduce, please check > the events for the openshift-infra namespace and the logs for the > hawkular-metrics pod. I suggest we open a separate bug to track. This happened every time when I tested last time. Now I have no logs on hand about this issue, and also could not set up a new env to get events and metrics logs due to bug 1390851, once the metrics can be deployed, I will check again, then will open a bug if reproduce again. Move this bug to Verified first.
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, 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/RHBA-2017:0066