Description of problem: ---------------------- I have observed a discrepancy in the costs reported between weekly and monthly Chargeback reports. Hourly chargeback rate has been assigned.I then created a weekly and a monthly Chargeback report.See attached Chargeback reports. VM = nachandr-5713-ssuif0001 period = Dec 01 - Dec 05, 2016 In the weekly report,the vCPU allocated cost for this VM = (24 + 24 + 24 + 24 + 24)$ = 120 $ In the monthly report, the vCPU allocated cost for Dec 2016 for this VM is 744$. Similarly, Storage Allocated cost in the weekly report = 120 $ Storage Allocated cost in the monthly repport = 744 $ Network I/O used cost in the weekly report = 60 $ Network I/O used cost in the monthly report = 372 $ Version-Release number of selected component (if applicable): ------------------------------------------------------------- 5.7.0.13 How reproducible: ---------------- Always Steps to Reproduce: ------------------- 1.Manage a provider. Collect C&U data for a few days(5 days in the attached report). 2.Generate weekly Chargeback report with this option : In the filter tab, in the Chargeback interval section,select 'Week' in the Chargeback Interval section. Generate weekly Chargeback report with this option : In the filter tab, in the Chargeback interval section,select 'Month' in the Chargeback Interval section. 3.Compare the costs reported in the two reports. Actual results: -------------- Expected results: ----------------- Additional info: ---------------
Created attachment 1228657 [details] Monthly Chargeback report
Created attachment 1228658 [details] Weekly Chargeback report
Created attachment 1228680 [details] Daily report
I compared a daily Chargeback report(and not a weekly report) with a monthly Chargeback report.
Taking, with Libor's permission. This is very nice catch, Nandini!
Actual results: -------------- The costs in the daily report are correct, but the costs in the monthly report are wrong. Expected results: ----------------- The costs in the monthly report should be the same as the costs in the daily report. Let's consider the example of the vCPU allocated cost. After generating a daily report, I summed up the vCPU allocated cost from Dec 01 - Dec 05 and the cost was 120 $.I generated a monthly report for the same period.The actual cost in the monthly report is 744, but the expected cost is the same as the one reported in the daily report, since the 2 different reports were generated for the same period.So, the expected cost is 120$.
https://github.com/ManageIQ/manageiq/pull/13134
Thanks Nandini for perfect analysis. The problem I found is that for fixed rate we charge also for the time that is yet to come. For instance, consider it is 2016-12-05 and with monthly we charge - the variable rate for whatever you have consumed so far and - the fixed rate for the whole month I think we should be consistent with this. We should not charge fixed and variable rate in different manner.
https://github.com/ManageIQ/manageiq/pull/13373
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/c94a8fbbb5274511aa46b05b9112e0ace1c38173 commit c94a8fbbb5274511aa46b05b9112e0ace1c38173 Author: Šimon Lukašík <isimluk> AuthorDate: Fri Dec 9 16:10:04 2016 +0100 Commit: Šimon Lukašík <isimluk> CommitDate: Thu Jan 5 16:45:29 2017 +0100 Do not charge for hours that are yet to come For variable_rate, we charge only that much that has been consumed. Perhaps I'll end the service tmrw, I should not be charged in advanced. https://bugzilla.redhat.com/show_bug.cgi?id=1402072 app/models/chargeback/consumption.rb | 12 ++++++++++-- app/models/chargeback/consumption_with_rollups.rb | 2 +- app/models/chargeback_rate_detail.rb | 2 +- 3 files changed, 12 insertions(+), 4 deletions(-)
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/3a678bb5ea0d6c5a5a17fd46c65d2d55f95b5f7e commit 3a678bb5ea0d6c5a5a17fd46c65d2d55f95b5f7e Author: Šimon Lukašík <isimluk> AuthorDate: Fri Jan 6 11:24:13 2017 +0100 Commit: Šimon Lukašík <isimluk> CommitDate: Fri Jan 6 11:24:13 2017 +0100 Specs: Fixed rate should charge only past hours https://bugzilla.redhat.com/show_bug.cgi?id=1402072 .../chargeback_vm/ongoing_time_period_spec.rb | 96 ++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 spec/models/chargeback_vm/ongoing_time_period_spec.rb
New commit detected on ManageIQ/manageiq/euwe: https://github.com/ManageIQ/manageiq/commit/24219e52a749fb6ca502a2d3f1bf063b3299142c commit 24219e52a749fb6ca502a2d3f1bf063b3299142c Author: Šimon Lukašík <isimluk> AuthorDate: Fri Dec 9 16:10:04 2016 +0100 Commit: Šimon Lukašík <isimluk> CommitDate: Wed Jan 18 10:09:45 2017 +0100 Do not charge for hours that are yet to come For variable_rate, we charge only that much that has been consumed. Perhaps I'll end the service tmrw, I should not be charged in advanced. https://bugzilla.redhat.com/show_bug.cgi?id=1402072 (cherry picked from commit c94a8fbbb5274511aa46b05b9112e0ace1c38173) app/models/chargeback/consumption.rb | 12 ++++++++++-- app/models/chargeback/consumption_with_rollups.rb | 2 +- app/models/chargeback_rate_detail.rb | 2 +- spec/models/chargeback_vm_spec.rb | 2 +- 4 files changed, 13 insertions(+), 5 deletions(-)
New commit detected on ManageIQ/manageiq/euwe: https://github.com/ManageIQ/manageiq/commit/70c9a58e87584fd291a0da65c4c291006c90b494 commit 70c9a58e87584fd291a0da65c4c291006c90b494 Author: Šimon Lukašík <isimluk> AuthorDate: Fri Jan 6 11:24:13 2017 +0100 Commit: Šimon Lukašík <isimluk> CommitDate: Wed Jan 18 10:09:45 2017 +0100 Specs: Fixed rate should charge only past hours https://bugzilla.redhat.com/show_bug.cgi?id=1402072 (cherry picked from commit 3a678bb5ea0d6c5a5a17fd46c65d2d55f95b5f7e) .../chargeback_vm/ongoing_time_period_spec.rb | 93 ++++++++++++++++++++++ 1 file changed, 93 insertions(+) create mode 100644 spec/models/chargeback_vm/ongoing_time_period_spec.rb
This issue affects 5.6.4 as well.Can this be cloned to 5.6?
I think the answer is yes. This can be cloned. You can use clone button to make the clone for 5.6. Then, the 3 ack process will be used to decide whether that bug is worth including into the 5.6. I have no visibility into how many releases are planned for 5.6.z. and I am not sure if there are any written policies for backporting to 5.6. Thus, it is still possible that the clone will never be fixed. However, it is worth filing, as it gives us visibility into what is broken in what versions. Thanks!
Verified in 5.8.0.10