Bug 1693047 - data format in console should be in align with that in the alert annotations
Summary: data format in console should be in align with that in the alert annotations
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: 4.1.0
Assignee: Andrew Pickering
QA Contact: Junqi Zhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-27 02:55 UTC by Junqi Zhao
Modified: 2019-06-04 10:46 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-04 10:46:29 UTC
Target Upstream Version:


Attachments (Terms of Use)
prometheus graph in alert details page (230.11 KB, image/png)
2019-03-27 02:55 UTC, Junqi Zhao
no flags Details
format is right now (218.57 KB, image/png)
2019-04-17 08:41 UTC, Junqi Zhao
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0758 None None None 2019-06-04 10:46:37 UTC

Description Junqi Zhao 2019-03-27 02:55:52 UTC
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.

Comment 1 Andrew Pickering 2019-04-16 05:48:08 UTC
It seems this was fixed by https://github.com/openshift/console/pull/1397

Comment 3 Junqi Zhao 2019-04-17 08:41:00 UTC
Created attachment 1555774 [details]
format is right now

Comment 4 Junqi Zhao 2019-04-17 08:53:17 UTC
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

Comment 6 errata-xmlrpc 2019-06-04 10:46:29 UTC
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


Note You need to log in before you can comment on or make changes to this bug.