Bug 1402072
Summary: | Discrepancy in costs reported between daily and monthly Chargeback reports | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat CloudForms Management Engine | Reporter: | Nandini Chandra <nachandr> | ||||||||
Component: | Reporting | Assignee: | Šimon Lukašík <slukasik> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Nandini Chandra <nachandr> | ||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | high | ||||||||||
Version: | 5.7.0 | CC: | cpelland, dajohnso, jhardy, obarenbo, simaishi, slukasik | ||||||||
Target Milestone: | GA | Keywords: | TestOnly, ZStream | ||||||||
Target Release: | 5.8.0 | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | chargeback | ||||||||||
Fixed In Version: | 5.8.0.0 | Doc Type: | If docs needed, set a value | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | |||||||||||
: | 1412221 1425915 (view as bug list) | Environment: | |||||||||
Last Closed: | 2017-06-12 17:18:47 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: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 1412221, 1425915 | ||||||||||
Attachments: |
|
Description
Nandini Chandra
2016-12-06 17:33:23 UTC
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$. 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. 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 |