Bug 1581718 - Weekly growth rate and week remaining metrics are not accurate
Summary: Weekly growth rate and week remaining metrics are not accurate
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: web-admin-tendrl-monitoring-integration
Version: rhgs-3.4
Hardware: All
OS: All
unspecified
urgent
Target Milestone: ---
: RHGS 3.4.0
Assignee: Ankush Behl
QA Contact: Daniel Horák
URL:
Whiteboard:
Depends On:
Blocks: 1503137
TreeView+ depends on / blocked
 
Reported: 2018-05-23 13:37 UTC by Anand Paladugu
Modified: 2018-09-04 07:07 UTC (History)
10 users (show)

Fixed In Version: tendrl-monitoring-integration-1.6.3-11.el7rhgs.noarch
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-09-04 07:06:51 UTC
Embargoed:


Attachments (Terms of Use)
weeks remaining screen shot (120.81 KB, image/png)
2018-06-18 17:26 UTC, Anand Paladugu
no flags Details
weeks remaining at volume level (187.33 KB, image/png)
2018-06-19 19:32 UTC, Anand Paladugu
no flags Details
Grafana Dashboard - Weeks Remaining showing negative number (11.38 KB, image/png)
2018-07-23 14:26 UTC, Daniel Horák
no flags Details
Graphite graphs: usable_capacity and used_capacity (mock data) (143.33 KB, image/png)
2018-07-26 14:28 UTC, Daniel Horák
no flags Details
Grafana weekly Growth Rate - positive number, Weeks Remaining negative number - mock data pushed into carbon (8.78 KB, image/png)
2018-07-26 14:30 UTC, Daniel Horák
no flags Details
weeks remaining screenshot with "Growth rate is negative in the selected duration" message (146.64 KB, image/png)
2018-08-14 09:02 UTC, Ankush Behl
no flags Details
Capacity available graph showing negative values with script (26.80 KB, image/png)
2018-08-16 07:00 UTC, Ankush Behl
no flags Details
Validation: Cluster Dashboard - corner cases (Capacity Available, Weekly Growth Rate, Weeks Remaining) (47.27 KB, image/png)
2018-08-21 09:46 UTC, Daniel Horák
no flags Details
Validation: Volume Dashboard - corner cases (Capacity Available, Weekly Growth Rate, Weeks Remaining) (47.52 KB, image/png)
2018-08-21 09:49 UTC, Daniel Horák
no flags Details
Issue with Weeks Remaining lower than 1 (but higher than 0) (20.05 KB, image/png)
2018-08-21 14:01 UTC, Daniel Horák
no flags Details
Issue with Weeks Remaining lower than 1 (but higher than 0) - graph of related data from graphite (14.42 KB, image/png)
2018-08-21 14:02 UTC, Daniel Horák
no flags Details
Weeks Remaining = 0 (16.67 KB, image/png)
2018-08-24 07:45 UTC, Daniel Horák
no flags Details
Weeks Remaining = 0 - graph of related data from graphite (13.98 KB, image/png)
2018-08-24 07:45 UTC, Daniel Horák
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github Tendrl monitoring-integration issues 538 0 None None None 2018-08-23 08:58:19 UTC
Github Tendrl monitoring-integration pull 535 0 None None None 2018-08-13 03:30:33 UTC
Red Hat Bugzilla 1549146 0 unspecified CLOSED Some huge numbers reported by grafana are hard to read and understand 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHSA-2018:2616 0 None None None 2018-09-04 07:07:42 UTC

Internal Links: 1549146

Description Anand Paladugu 2018-05-23 13:37:35 UTC
Description of problem:
Weekly growth rate and weeks remaining metrics are not accurate.  I have used a setup with two volumes (one 11.2 % full and one empty) and data from one volume to the other (~ 40 GB) several times in a loop of copying and removing. Before the test weekly growth and  weeks remaining was NA. My testing was all done in a couple of hours, but yet weekly growth rate jumped to 183GB or something like that and weeks remaining became 1.7 weeks.  At the rate I was filling the volume, I probably don't really have 1.7 weeks and also it looks like deletes are not being calculated for growth calculations, because when I deleted files, capacity shows the available space correctly, but growth and weeks remaining did not reflect change after deletes.

Version-Release number of selected component (if applicable): 3.4



How reproducible:
Generate traffic to fill volumes and delete data in a loop and check for growth and weeks remaining computations in each iteration.


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Ankush Behl 2018-05-25 13:15:48 UTC
@apaladug For finding the weekly growth and weeks remaining the graphs expect a day's data to provide some and amount of accuracy and the weeks time to provide the good amount of accuracy.

As the query written in grafana to calculate the weekly growth and weeks remaining are expecting that data and is copied from how ceph metrics project is calculating the weekly growth and weeks remaining.

can you tell the level of accuracy we are looking from the weekly growth and weeks remaining?

Below is code for how we are calculating weekly growth and weeks remaining:

Weekly Growth:
https://github.com/Tendrl/monitoring-integration/blob/b064fdcaaba2b46da871855c9e54dea831f459fa/etc/tendrl/monitoring-integration/grafana/dashboards/tendrl-gluster-at-a-glance.json#L1167

Weeks Remaining
https://github.com/Tendrl/monitoring-integration/blob/b064fdcaaba2b46da871855c9e54dea831f459fa/etc/tendrl/monitoring-integration/grafana/dashboards/tendrl-gluster-at-a-glance.json#L1234

Comment 3 Rohan Kanade 2018-05-30 11:08:14 UTC
@Ankush

We should have different queries for calculating growth and other stats if
- data is collected for only the last 3-4 days
- data is collected for more than the last 7 days.

Comment 4 Anand Paladugu 2018-05-30 16:39:57 UTC
Agree with this approach.

Comment 5 Ankush Behl 2018-05-30 16:49:30 UTC
@rkanade @apaladug I am doing a research if that's even possible to add the condition on showing different value for different scenarios.

Comment 6 Ankush Behl 2018-06-07 11:00:44 UTC
@rohan @anand I didn't found any way to jump between the conditions in grafana based upon any sort of metric. 

So I could not have two different queries for the single panel.

Comment 7 Anand Paladugu 2018-06-18 17:25:30 UTC
I am fine with lesser accuracy in the beginning as data builds up. Butlet us make sure that the existing logic works well.

I was just playing with the sandbox setup and selected 7 day time period (for 2 days I think the week remaining panel said "There is not enough data".

Capacity available is 123.8 GB,  Weekly growth Rate is 20.4 GiB,  and weeks remaining is  "-1796"

This cannot be right.     Attached the screen shot.

Comment 8 Anand Paladugu 2018-06-18 17:26:25 UTC
Created attachment 1452700 [details]
weeks remaining screen shot

Comment 9 Nishanth Thomas 2018-06-19 08:48:48 UTC
@Martin,, Could you please verify the behaviour and we will take it forward from there

Comment 10 Anand Paladugu 2018-06-19 19:32:25 UTC
Created attachment 1453017 [details]
weeks remaining at volume level

Comment 13 Daniel Horák 2018-07-23 14:26:26 UTC
Created attachment 1469971 [details]
Grafana Dashboard - Weeks Remaining showing negative number

Comment 14 Daniel Horák 2018-07-23 14:35:52 UTC
There is one quite easy scenario, when it shows negative number as Weeks Remaining value (attachment 1469971 [details]) - which is definitely wrong and should be handled somehow differently.

In my case I've used mock data generated by script based on Bug 1549146 comment 12 - but it should be reproducible just by constantly deleting small amount of data from the cluster for more than one week (so the 'used_capacity' value will be lesser and lesser during the week).

I'll polish the script used for generating the data and make it public (hopefully tomorrow) - so it will be easier for you to generate various patterns of values.

Comment 15 Daniel Horák 2018-07-24 12:00:30 UTC
Here is the script used for generating data for grafana, please let me know, if you will find any issue (I might miss something) or if you will need help with using it:
  https://github.com/dahorak/usmqe-carbon-mock-data-generator

@Ankush, would it be possible to use this script to speed up the development and testing of this BZ?

Comment 16 Ankush Behl 2018-07-24 15:18:01 UTC
@daniel Thanks for the script. I understand we can use it for checking the negative values but I am more concerned about the correction of the data right now. I have a cluster running for 4 days now. Will try to push and remove some data tomorrow and see how it responds and what's the data accuracy it is giving.

Comment 17 Daniel Horák 2018-07-26 14:28:56 UTC
Created attachment 1470796 [details]
Graphite graphs: usable_capacity and used_capacity (mock data)

Comment 18 Daniel Horák 2018-07-26 14:30:11 UTC
Created attachment 1470797 [details]
Grafana weekly Growth Rate - positive number, Weeks Remaining negative number - mock data pushed into carbon

Comment 19 Daniel Horák 2018-07-26 14:48:16 UTC
I was able to simulate similar behaviour as described in the Description
and showed in the attachment 1452700 [details] - see my attached screenshot
attachment 1470797 [details] (Weekly growth rate shows quite high positive number and
weeks remaining shows negative number.)

On the screenshot in attachment 1470796 [details], you can see what data I've generated
for the particular volume "usable_capacity" and "used_capacity":
  * blue line is "usable_capacity" set to constant number 104857600 (100GB)
  * green line is "used_capacity" with generated slowly rising sinus
    (combined linear growing value + sinus)

Configuration file for usmqe-carbon-mock-data-generator mentioned in comment 15
looks like this:
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ---
  - filter: "usable_capacity"
    generators:
      - name: constant
        value: 104857600 # 100GB
  
  - filter: "used_capacity"
    generators:
      # constant value around 90GB
      # to get the two lines usable_capacity and used_capacity closely together
      - name: constant
        value: 90000000
      # linear growing "line" from 0 to ~2,5GB
      - name: linear
        value_a: 0
        value_b: 2560000
      # (reverted) sinus function with peak-to-peak ~10GB 
      - name: sin
        value_b: 0
        value_a: 10240000
        period: 64000
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTE: the value for used_capacity graph is combined as sum of the three partial
values

I know, that the course of used_capacity is purely generated as mock data, so
real usage will looks differently, but some kind of "variation around slowly
growing value" might be quite real scenario.

Comment 20 Ankush Behl 2018-07-31 14:37:38 UTC
I ack that we are getting the negative  value for weeks remaining and weekly growth. 

So the weekly growth panel can have negative values when there is a decrease in the storage utilization over a period of time( When the files are getting deleted from the volume), but the weeks remaining in this case cannot be actually calculated because it's a negative growth.


Thus, it is proposed that we will show proper text which says that weeks remaining cannot be calculated for the negative growth.

@dahorak - please ack if the above suggestion makes sense to you. 

@ju- Can you suggest some text that implies to the above scenario. 

Query we are going to use for calculation:
1. summarize(timeShift(tendrl.names.$cluster_id.volumes.$volume_name.used_capacity, '7d'), '1d', 'avg')
2. summarize(timeShift(tendrl.names.$cluster_id.volumes.$volume_name.used_capacity, '0d'), '1d', 'avg')

Comment 21 Daniel Horák 2018-08-01 06:40:26 UTC
@Ankush, did I understand it right, that the query (1. and 2.) will be same
for both "Weekly Growth Rate" and "Weeks Remaining"?

Comment 22 Daniel Horák 2018-08-01 06:43:31 UTC
(In reply to Ankush Behl from comment #20)
> @dahorak - please ack if the above suggestion makes sense to you. 

Otherwise yes, I agree with the proposal in comment 20.

Comment 24 Martin Bukatovic 2018-08-01 16:21:30 UTC
While I see some comments about implementation details of the fix, I need to note
down a clear summary of what is going to change from end user point of view,
so that this would be understandable for dev, qe and pm before acking this BZ.

And so far, I can see that we have 2 changes (and 2 scenarios for qe team to
validate) here.

1) For cases when the dashboard previously reported negative predictions, message
about not enough data (or something similar) will be reported instead. This is
clear, qe can test this using Daniel's script from comment 19.

2) There is another set of changes discussed in comment 12 and comment 20, but I
don't understand the user impact here, so that qe don't know how to validate
this.

Could the dev team provide missing details for the 2nd case, so that both qe
and pm understands the implications of this change? During bug triage meeting,
I have agreed to ack this, but under assumption that Nishanth will provide the
summary of the changes here.

Comment 25 Ankush Behl 2018-08-02 08:45:42 UTC
> 2) There is another set of changes discussed in comment 12 and comment 20,
> but I
> don't understand the user impact here, so that qe don't know how to validate
> this.

@martin - the older query we have right now we used take the max value of the yesterday's day and the max value week before and then used to calculate the the weekly growth and weeks remaining.

So the query has two problems:

1. we are taking yesterday's value to calculate. So the value was not shown as per the current date/time and also the time difference between yesterday and 7th day from today is 6 days which we were considering as week which is not correct.

2. The second problem was we were taking the max value of both the day's to calculate which can eventually give wrong stats so have thought of doing the avg(mean value) of the both the today's value and week before. So that we can get some consistency.

So the query mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1581718#c20 is the one I am going to use to calculate both weeks remaining and weekly growth.

if any more clarity is required we can discuss over a bluejeans. Thanks

Comment 26 Ju Lim 2018-08-02 13:03:01 UTC
In reviewing proposed changes mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1581718#c25, I am fine with the latest proposal, i.e. to use average value for the day vs. max value for the day.  There may be some small set of scenarios where the forecasted values may be less "accurate" e.g. short-lived / batch jobs, but let's try it with the avg as the more common scenario would be satisfied with the avg value.

When calculate weekly growth values are negative, it usually indicates we have insufficient data collected to give a reliable forecast.  In such scenarios, we should indicate that via some kind of text, e.g. "Insufficient data" or "N/A".

Comment 27 Daniel Horák 2018-08-03 12:54:07 UTC
@Ankush, the "today's" average value is for last 24 hours, or from 00:00 today - which might be for example just 14 hours, or few minutes - if it will be just after midnight?

Comment 28 Martin Bukatovic 2018-08-03 13:30:10 UTC
(In reply to Ankush Behl from comment #25)
> > 2) There is another set of changes discussed in comment 12 and comment 20,
> > but I
> > don't understand the user impact here, so that qe don't know how to validate
> > this.
> 
> @martin - the older query we have right now we used take the max value of
> the yesterday's day and the max value week before and then used to calculate
> the the weekly growth and weeks remaining.
> 
> So the query has two problems:
> 
> 1. we are taking yesterday's value to calculate. So the value was not shown
> as per the current date/time and also the time difference between yesterday
> and 7th day from today is 6 days which we were considering as week which is
> not correct.
> 
> 2. The second problem was we were taking the max value of both the day's to
> calculate which can eventually give wrong stats so have thought of doing the
> avg(mean value) of the both the today's value and week before. So that we
> can get some consistency.

So do I read it right that the change is about:

 * changing which 2 days are used as a base for the calculation (it was
   yesterday and day 7 days ago, but now it's today and day 7 days ago)

 * instead of max() function applied to both days, we are going to use
   some avg() function instead

Ok, but for me to test this, I need to understand *what do you expect to be
better* and how could this be measure. An example of use case, with description
why would be the new extrapolation better in such case. This is important for
Anand as well, to see what impact this fix will have.

Based on that, I can verify that these expectations holds and that everything
works as expected.

Extrapolating data is not easy and without exact intentions, I could always
find an example of data which would result in weird predictions, especially
given how simple our current model is.

> if any more clarity is required we can discuss over a bluejeans. Thanks

Ok, I will schedule a meeting on Monday. I couldn't reach you today because
of unexpected issues.

Comment 29 Anand Paladugu 2018-08-10 10:27:16 UTC
While I agree going with average value, but why cannot we show -ve growth if growth is indeed -ve (rather than saying insufficient data) ?

Comment 30 Anand Paladugu 2018-08-10 12:01:17 UTC
"Insufficient data" or "N/A" does not sound appropriate for me since it's not the lack of information that we have but a way to represent it more meaningfully. We should change the verbiage to make it sound like -ve growth.

Comment 31 Martin Bukatovic 2018-08-10 13:46:55 UTC
Based on bug triage meeting on 2018-08-10, QE is acking this with new
set of assumptions about the fix. This invalidates previous qe summaries of
fix for this bug completely:

 * something else (whatever it is) is reported instead of negative numbers,
   which makes more sense then previous behavior (negative weeks remaining
   is still considered wrong, reporting insufficient data as well)

 * using Daniels example from comment 19, we will try to do the math based
   on the numbers reported and check if it works reasonably well

This means that the team agreed on the fact that only fuzzy and little
improvement is expected, without clear, measurable validation criteria.

Comment 33 Ankush Behl 2018-08-12 17:40:54 UTC
(In reply to Anand Paladugu from comment #30)
> "Insufficient data" or "N/A" does not sound appropriate for me since it's
> not the lack of information that we have but a way to represent it more
> meaningfully. We should change the verbiage to make it sound like -ve growth.

@ju -  can you suggest some text which indicates the -ve growth instead of N/A or Insufficient data.

Comment 34 Ankush Behl 2018-08-12 17:42:35 UTC
(In reply to Daniel Horák from comment #27)
> @Ankush, the "today's" average value is for last 24 hours, or from 00:00
> today - which might be for example just 14 hours, or few minutes - if it
> will be just after midnight?

@daniel - I will be taking the last 24 hour data to calculate the value.

Comment 35 Ju Lim 2018-08-13 15:58:10 UTC
@Ankush

The negative values occur when there is negative growth, e.g. when data is deleted from the storage based on the average utilization for the selected day(s) used in the computation.  These are some text suggestions when negative growth is computed:

   "Growth rate is decreasing"

@Bobb - Any thoughts on this or would you suggest some other text?

@Anand - FYI.

Comment 36 Ju Lim 2018-08-14 00:34:10 UTC
Per Anand: "Decreasing" indicates a trend, which we are not certain off.  Maybe we should just say "Growth rate is negative in the selected duration".


Please change to "Growth rate is negative in the selected duration".

Comment 37 Ankush Behl 2018-08-14 09:02:30 UTC
Created attachment 1475777 [details]
weeks remaining screenshot with "Growth rate is negative in the selected duration" message

Comment 38 Ankush Behl 2018-08-14 09:07:44 UTC
(In reply to Ju Lim from comment #36)
> Per Anand: "Decreasing" indicates a trend, which we are not certain off. 
> Maybe we should just say "Growth rate is negative in the selected duration".
> 
> 
> Please change to "Growth rate is negative in the selected duration".


The above provided text message is not getting fit into the panel (attachment 1475777 [details]) and it's disturbing the alignment of the panel. So we are going with short message of showing the "Growth rate is negative"[1] rather than "Growth rate is negative in the selected duration".

The new text("Growth rate is negative") is getting fit into the panel properly and not causing any issues.

[1]. https://github.com/Tendrl/monitoring-integration/pull/535/files#diff-074543c9c78ef2c262e63fb311756b79R1227

Comment 40 Ju Lim 2018-08-15 19:53:01 UTC
Is there anyway to make the text appear smaller (for the non computed value), e.g. "Insufficient data collected for forecast" and for the "Growth rate is negative"?

Comment 41 Ankush Behl 2018-08-16 06:37:54 UTC
@ju - No grafana doesn't provide that functionality of giving different font size for different message in single panel.

Comment 42 Ankush Behl 2018-08-16 06:58:56 UTC
@daniel - I  tried the script provided by you in comment #15 comment #19 to simulate the negative scenario. I suppose your didn't stop monitoring-integration when you started pushing the mock value.

I plotted the graph in grafana and I saw that monitoring integration and mock-data is creating different set of values at one point and the capacity available is going in negative and grafana is plotting a negative graph for capacity available which will not be actual case scenario. 

so I will suggest if you are using the mock values to simulate the negative scenario then stop monitoring integration before generating the mock data scenario.

Comment 43 Ankush Behl 2018-08-16 07:00:41 UTC
Created attachment 1476366 [details]
Capacity available graph showing negative values with script

Comment 44 Daniel Horák 2018-08-16 11:58:02 UTC
@Ankush, my scenario was as follows:
1. Install and configure Gluster Cluster and RHGS WA
2. Import Gluster Cluster into RHGS WA
3. Wait some time to be sure that all the required structures for data were
   created. I've periodically check the list of available metrics using
   following command and check if the number of lines is not changing for
   some time:
   # ./usmqe_carbon_mock_data_generator.py -s server.example.com list | wc -l
4. Power off all Gluster Storage machines.
5. Generate the mock data using the usmqe_carbon_mock_data_generator script.

Is this sufficient?

Comment 45 Ankush Behl 2018-08-16 12:27:32 UTC
(In reply to Daniel Horák from comment #44)
> @Ankush, my scenario was as follows:
> 1. Install and configure Gluster Cluster and RHGS WA
> 2. Import Gluster Cluster into RHGS WA
> 3. Wait some time to be sure that all the required structures for data were
>    created. I've periodically check the list of available metrics using
>    following command and check if the number of lines is not changing for
>    some time:
>    # ./usmqe_carbon_mock_data_generator.py -s server.example.com list | wc -l
> 4. Power off all Gluster Storage machines.
> 5. Generate the mock data using the usmqe_carbon_mock_data_generator script.
> 
> Is this sufficient?

@daniel- It looks good to me!

Comment 46 Daniel Horák 2018-08-21 09:46:38 UTC
Created attachment 1477468 [details]
Validation: Cluster Dashboard - corner cases (Capacity Available, Weekly Growth Rate, Weeks Remaining)

a) Weeks remaining is calculated to 520 or more weeks -> message "Insufficient data collected for forecast" is displayed instead of the number.

b) Weeks remaining is calculated to 519 weeks.

c) Corner case for huge available capacity and very slow growth rate (unreal data) -> weeks remaining is calculated to very high number and thus message "Insufficient data collected for forecast" is displayed instead of the number.

d) Similar to previous case, but the growth rate is negative - still the trend is properly recognized and message "Growth rate is negative" is displayed.

Comment 47 Daniel Horák 2018-08-21 09:49:04 UTC
Created attachment 1477469 [details]
Validation: Volume Dashboard - corner cases (Capacity Available, Weekly Growth Rate, Weeks Remaining)

Apply the same description as for Cluster Dashboard in previous comment (e=a, f=b, g=c, h=d).

Comment 48 Daniel Horák 2018-08-21 11:52:10 UTC
@Ankush, how selecting different time range affects the Weekly growth rate and Weeks remaining values? And should it be somehow affected?

Comment 49 Ankush Behl 2018-08-21 13:55:19 UTC
(In reply to Daniel Horák from comment #48)
> @Ankush, how selecting different time range affects the Weekly growth rate
> and Weeks remaining values? And should it be somehow affected?

For finding the available capacity in weeks remaining we are not summarizing the it by day or week that's why when you change the timings it affects the graph.

There was some limitation I was facing while fixing it. so you can think we can create a different bugzilla for 3.4 later to fix that.

Comment 50 Daniel Horák 2018-08-21 14:01:41 UTC
Created attachment 1477518 [details]
Issue with Weeks Remaining lower than 1 (but higher than 0)

Comment 51 Daniel Horák 2018-08-21 14:02:27 UTC
Created attachment 1477519 [details]
Issue with Weeks Remaining lower than 1 (but higher than 0) - graph of related data from graphite

Comment 52 Daniel Horák 2018-08-21 14:09:00 UTC
There is one quite significant problem with the "Weeks Remaining" panel which occur, when the cluster is nearly full and the calculated time for Weeks Remaining is lower than one week.

In other words, if Capacity Available is lower than Weekly Growth Rate, the "Weeks Remaining" should be between 0 and 1, but this value is mapped to "Growth rate is negative" message, which is quite misleading - see attachment 1477518 [details].

Also on attachment 1477519 [details], you can see one week of data for usable_capacity and used_capacity metrics  it is quite obvious, that with this utilization pattern, the cluster will be full in less than one week.

Affected version of related packages:
  carbon-selinux-1.5.4-2.el7rhgs.noarch
  collectd-5.7.2-3.1.el7rhgs.x86_64
  collectd-ping-5.7.2-3.1.el7rhgs.x86_64
  grafana-4.3.2-3.el7rhgs.x86_64
  libcollectdclient-5.7.2-3.1.el7rhgs.x86_64
  python-carbon-0.9.15-2.1.el7rhgs.noarch
  tendrl-ansible-1.6.3-7.el7rhgs.noarch
  tendrl-api-1.6.3-5.el7rhgs.noarch
  tendrl-api-httpd-1.6.3-5.el7rhgs.noarch
  tendrl-commons-1.6.3-12.el7rhgs.noarch
  tendrl-grafana-plugins-1.6.3-10.el7rhgs.noarch
  tendrl-grafana-selinux-1.5.4-2.el7rhgs.noarch
  tendrl-monitoring-integration-1.6.3-10.el7rhgs.noarch
  tendrl-node-agent-1.6.3-10.el7rhgs.noarch
  tendrl-notifier-1.6.3-4.el7rhgs.noarch
  tendrl-selinux-1.5.4-2.el7rhgs.noarch
  tendrl-ui-1.6.3-11.el7rhgs.noarch

>> ASSIGNED

Comment 54 Daniel Horák 2018-08-24 07:45:05 UTC
Created attachment 1478418 [details]
Weeks Remaining = 0

Comment 55 Daniel Horák 2018-08-24 07:45:56 UTC
Created attachment 1478419 [details]
Weeks Remaining = 0 - graph of related data from graphite

Comment 56 Daniel Horák 2018-08-24 07:47:07 UTC
Issue described in comment 52 were fixed - see attachment 1478418 [details] and relevant data from graphite attachment 1478419 [details].

Comment 57 Daniel Horák 2018-08-24 08:38:19 UTC
Precision of the prediction for Weeks Remaining metrics depends on the
utilization grow pattern and is limited by the linear prediction from
average value from last 24 hours and 7 days back.

For steadily growing trends, the prediction is reasonably accurate.
For dynamically changing utilization (adding and deleting huge amount of data)
the prediction might not be too precise.

Corner cases are handled reasonably well (see comment 46, comment 47 and
comment 56).

Question related to changing time range affecting the values was raised as
separated bug 1622017.

Lastly tested on following versions of affected components:
  grafana-4.3.2-3.el7rhgs.x86_64
  tendrl-ansible-1.6.3-7.el7rhgs.noarch
  tendrl-api-1.6.3-5.el7rhgs.noarch
  tendrl-api-httpd-1.6.3-5.el7rhgs.noarch
  tendrl-commons-1.6.3-12.el7rhgs.noarch
  tendrl-grafana-plugins-1.6.3-11.el7rhgs.noarch
  tendrl-grafana-selinux-1.5.4-2.el7rhgs.noarch
  tendrl-monitoring-integration-1.6.3-11.el7rhgs.noarch
  tendrl-node-agent-1.6.3-10.el7rhgs.noarch
  tendrl-notifier-1.6.3-4.el7rhgs.noarch
  tendrl-selinux-1.5.4-2.el7rhgs.noarch
  tendrl-ui-1.6.3-11.el7rhgs.noarch

>> VERIFIED

Comment 59 errata-xmlrpc 2018-09-04 07:06:51 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/RHSA-2018:2616


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