Created attachment 1400847 [details]
Description of problem:
Some of the numbers displayed on Grafana dashboards could be very high
and it is quite difficult, to read and understand the magnitude of the
particular number. See attached screenshots, for example:
- Weeks Remaining
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Gluster cluster with (ideally some real world scenario).
2. Install Web Administration (Tendrl) and import the Gluster cluster.
3. Utilize the Gluster cluster (make some load, read/write operations..)
4. Let it run for few days, so there will be some meaningful data.
5. Check Grafana Dashboards.
Some of the numbers displayed by Grafana are very high and it's difficult
to understand and imagine the magnitude of the number.
For example "Weeks Remaining": 1629077.
The numbers displayed by Grafana dashboards will be nicely human readable.
There are multiple ways how to accomplish this and it will probably depend
on the type of the displayed value.
"Weeks Remaining" probably doesn't make much sense to show
exact numbers for more than few years (and it might make sense to recalculate
the number of weeks to number of months or years for longer periods).
"Inode available" as this number doesn't have any unit (to prepend it with
k,M,G...) it might make sense to show the number in form like:
3124138767 ~ 3.1*10^9
or something like that.
Related bug in GitHub: https://github.com/Tendrl/monitoring-integration/issues/383
I'm providing qe_ack with following assumptions:
* devel team will provide a module to generate mock data for tendrl ui component
so that integration testing of units of measure feature is possible
(this mitigates the risk of qe team not being able to simulate all scenarios
during system testing, especially for IOPS, throughput and weeks remaining)
* qe team will verify selected edge cases during system testing to make sure
that values reported are matching reality (eg. IOPS, weeks remaining)
This has been agreed on during "RHGS WA Team status meeting" on 2018-03-29.
Asking about requires_doc_text flag, as this changes how numbers are reported in
the web interface.
Moving back to assigned because the dev team haven't provided mock module as
agreed in comment 4.
Provide the module along with description how it was used during dev testing,
and move this BZ into ON QA again.
@ankush, Do we have means to provide mock module for verification?
@Daniel, BTW how Daniel did this when the bug found?
@email@example.com We don't have any script right now for pushing the mock data.
If we want something like this then we need to put an effort in writing the script.
AND Yes its better if we have the script for pushing the data to graphite that will help QE and Dev both in testing.
If I remember it correctly, the bug was filed against cluster with 24 or 36
We are able, to test the one (same/similar) scenario for which it was reported,
but we are not easily able to retest multiple different scenarios and edge cases.
All our resources are very limited, so for example we are able to simulate
big disks, but we are not able to fill them, as we haven't physically enough
That was the reason, why Martin asked for a module to generate mock data.
@firstname.lastname@example.org @email@example.com I have written a script that can help QE generate and push mock data in carbon/graphite.
Steps to use a script:
1. Clone the Repo carbon-random.
2. open carbon_random.py
3. Provide IP address of the graphite/carbon
4. Put the name metrics you want to search for(In this bug we want to push data to IOPS metric)
5. Select the Lower and Upper bound values for the random integer data you want to push.
6. Select at which interval you want to push data to graphite.
7. Save and run "python carbon_random.py"
Created attachment 1459687 [details]
IOPS Dashboard - units prefix B
@Ju, now the IOPS values are displayed with following suffix for the number:
What does means the "B" suffix? (see also attachment 1459687 [details])
If it is based on SI prefixes, shouldn't it be "G" instead of "B"?
And also shouldn't be "k" lowercase?
Created attachment 1469965 [details]
Grafana Dashboard - Weeks Remaining showing huge number (tendrl-monitoring-integration-1.6.3-7.el7rhgs.noarch)
Tested and Verified on:
Red Hat Enterprise Linux Server release 7.5 (Maipo)
* All IOPS panels shows values with proper suffix (as described in Comment 14)
* Weeks Remaining panels shows numbers between 1-520,
for numbers lower than 0, it shows: Growth rate is negative
and for numbers higher than 520 it shows:
Insufficient data collected for forecast
* Inode Available panels were removed
 Behaviour of Weeks Remaining panel is more discussed and controlled in
Also there is one small issue described in Bug 1581718 comment 52,
which will be processed as part of that bug.
Overall looks good but this bug also targets the removal of INode panel removal from brick and volume dashboards.
So I think we should also include some text about the Inode panel removal.
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.