Bug 1614005
| Summary: | It's not clear what Weeks Remaining panel on Host dashboard mean | ||
|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat Gluster Storage | Reporter: | Martin Bukatovic <mbukatov> |
| Component: | web-admin-tendrl-monitoring-integration | Assignee: | gowtham <gshanmug> |
| Status: | CLOSED ERRATA | QA Contact: | Elena Bondarenko <ebondare> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rhgs-3.4 | CC: | anbehl, apaladug, asachan, ebondare, gshanmug, julim, nthomas, rghatvis, rhinduja, rhs-bugs, sankarshan, shtripat |
| Target Milestone: | --- | Keywords: | ZStream |
| Target Release: | RHGS 3.4.z Batch Update 1 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | tendrl-monitoring-integration-1.6.3-13.el7rhgs | Doc Type: | Bug Fix |
| Doc Text: |
The Weeks Remaining panel in the Host and Cluster dashboard of Grafana did not display complete and accurate metrics about the remaining weeks for volumes utilization due to inaccurate predictions.
To avoid projecting any false or inaccurate metrics, the Weeks Remaining panel is now removed from the Host and Cluster Dashboard of Grafana.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-31 08:45:18 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: | |||
The same problem applies for "Weeks Remaining" panel on Cluster dashboard. (In reply to Martin Bukatovic from comment #1) > The same problem applies for "Weeks Remaining" panel on Cluster dashboard. @martin - can you explain why it doesn't make sense on cluster dashboard. I agree it doesn't make sense on the host dashboard because we are showing weeks remaining for the bricks that are there on the host. We will remove it from host dashboard. (In reply to Ankush Behl from comment #3) > (In reply to Martin Bukatovic from comment #1) > > The same problem applies for "Weeks Remaining" panel on Cluster dashboard. > > @martin - can you explain why it doesn't make sense on cluster dashboard. Imagine you are saving incoming data on a gluster volume, but other volumes maintains it's utilization stable. Now you see some number reported on Weeks Remaining panel for the whole cluster and wonder: does it take into account the fact that only volume with utilization going up will be able to receive the data? Let's demonstrate this on particular example. You have a cluster with volumes: * volume A, which is filling up, and WA reports just 2 weeks as remaining * volume B, which is not filling up, maintains stable utilization, and WA doesn't try to guess this because there is not enough data Now, what should "Weeks remaining" for the whole cluster be? If you just sum up the values for remaining free space and incoming data, the resulting number would not make sense as the data which are uploaded on volume A would not be magically stored on volume B instead when we run out of free space on volume A. So I guess this is not the case. But then the question is, how is this number actually calculated? > I agree it doesn't make sense on the host dashboard because we are showing > weeks remaining for the bricks that are there on the host. We will remove it > from host dashboard. Ack, I have no problem with that. That said, we need to ask Anand. Raising needinfo for 1st part of comment 4 (weeks remaining on Cluster Dashboard). Weeks remaining on whole cluster does not make sense, unless the assumption is that all volumes and bricks are filling up at the same rate ... It has to be on a volume by volume basis. Plus from a customer perspective, consumption is from a volume perspective. Action Item: Remove Weeks Remaining panel on Cluster and Host Dashboard. remove weeks remaining and forecasted weekly from host and cluster dashboard, stretch remaining panels on the row. Providing the acks based on https://bugzilla.redhat.com/show_bug.cgi?id=1614005#c9 PR is under review: https://github.com/Tendrl/monitoring-integration/pull/565 There's no Weeks Remaining panel on either Host or Cluster dashboard. Looks good. Looks good to me 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-2018:3427 |
Description of problem ====================== When a machine hosts bricks of multiple volumes, what does the value reported here mean? I mean, imagine you are saving incoming data on a gluster volume, but other volumes maintains it's utilization stable. Now you see some number reported on Weeks Remaining panel and wonder: does it take into account the fact that only bricks of the volume with utilization going up will be able to receive the data? Or does it ignore this limitation? Version-Release number of selected component ============================================ tendrl-monitoring-integration-1.6.3-7.el7rhgs.noarch Steps to Reproduce ================== 1. Instal RHGS WA using tendrl-ansible 2. Import Trusted storage pool with at least two volumes, so that each storage machine hosts bricks of both volumes 3. Run a workload, uploading data on one volume, while keep the other volume idle 4. Go to Host dashboard and check Weeks Remaining panel Actual results ============== The description of the panel: > The Weeks Remaining panel displays the estimated time remaining in > weeks till host capacity reaches full capacity based on the forecasted > Weekly Growth Rate. Doesn't explain the way Weeks Remaining prediction is computed when host contains bricks of multiple volumes. Does it take into account that extrapolated growth wrt the volume? Expected results ================ It's clear how the data are aggregated, when storage machine hosts bricks of multiple volumes. Additional question =================== Which of the solution is correct (wrt what would gluster administrators like to see reported here) remains not specified.