Bug 1693047
| Summary: | data format in console should be in align with that in the alert annotations | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Junqi Zhao <juzhao> | ||||||
| Component: | Management Console | Assignee: | Andrew Pickering <anpicker> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Junqi Zhao <juzhao> | ||||||
| Severity: | low | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 4.1.0 | CC: | anpicker, aos-bugs, jokerman, mmccomas | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | 4.1.0 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | No Doc Update | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2019-06-04 10:46:29 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: |
|
||||||||
It seems this was fixed by https://github.com/openshift/console/pull/1397 Created attachment 1555774 [details]
format is right now
Tested with 4.0.0-0.nightly-2019-04-10-182914, data format is right now although there are 3 values in the page 1. 11.596099810274021 -- prometheus raw data 2. 11.60 -- in DESCRIPTIONACTIVE part of alert 3. 11.5961 -- mouse hover the line The UI can only control the format of: (1) the graph hover value, (2) the value in the VALUE column But the VALUE column is the raw value, so I think we should probably leave that alone We can't really make the hover format match the description format because we don't know what the description format is (it can be different for every alerting rule). And I don't think we want it to match the raw value because that can be too many digits, so harder to read. (edited) So having 3 different formats on the same page is not perfect, but it's probably the best approac 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-2019:0758 |
Created attachment 1548360 [details] prometheus graph in alert details page Description of problem: consume the alertmanager storage to tigger KubePersistentVolumeFullInFourDays alert see the attached picture, one available percentage is 5.361159810113915, the other is 11.595699544497547 But the console treats them as 5.4 and 12 I think the format should be "%0.2f", in align with KubePersistentVolumeFullInFourDays annotations Version-Release number of selected component (if applicable): 4.0.0-0.nightly-2019-03-25-180911 How reproducible: Always Steps to Reproduce: 1. consume the alertmanager storage to tigger KubePersistentVolumeFullInFourDays alert and go to the alert rule details page and check the graph 2. 3. Actual results: console treats them as 5.4 and 12 Expected results: data format in console should be in align with that in the alert annotations Additional info: KubePersistentVolumeFullInFourDays expression: 100 * (kubelet_volume_stats_available_bytes{job="kubelet",namespace=~"(openshift-.*|kube-.*|default|logging)"} / kubelet_volume_stats_capacity_bytes{job="kubelet",namespace=~"(openshift-.*|kube-.*|default|logging)"}) < 15 and predict_linear(kubelet_volume_stats_available_bytes{job="kubelet",namespace=~"(openshift-.*|kube-.*|default|logging)"}[6h], 4 * 24 * 3600) < 0 annotations: Based on recent sampling, the PersistentVolume claimed by {{ $labels.persistentvolumeclaim }} in Namespace {{ $labels.namespace }} is expected to fill up within four days. Currently {{ printf "%0.2f" $value }}% is available.