Bug 1402072

Summary: Discrepancy in costs reported between daily and monthly Chargeback reports
Product: Red Hat CloudForms Management Engine Reporter: Nandini Chandra <nachandr>
Component: ReportingAssignee: Šimon Lukašík <slukasik>
Status: CLOSED CURRENTRELEASE QA Contact: Nandini Chandra <nachandr>
Severity: high Docs Contact:
Priority: high    
Version: 5.7.0CC: cpelland, dajohnso, jhardy, obarenbo, simaishi, slukasik
Target Milestone: GAKeywords: 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 Flags
Monthly Chargeback report
none
Weekly Chargeback report
none
Daily report none

Description Nandini Chandra 2016-12-06 17:33:23 UTC
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:
---------------

Comment 2 Nandini Chandra 2016-12-06 17:41:20 UTC
Created attachment 1228657 [details]
Monthly Chargeback report

Comment 3 Nandini Chandra 2016-12-06 17:42:09 UTC
Created attachment 1228658 [details]
Weekly Chargeback report

Comment 4 Nandini Chandra 2016-12-06 20:52:15 UTC
Created attachment 1228680 [details]
Daily report

Comment 5 Nandini Chandra 2016-12-06 20:54:00 UTC
I compared a daily Chargeback report(and not a weekly report) with a monthly Chargeback report.

Comment 7 Šimon Lukašík 2016-12-09 14:44:09 UTC
Taking, with Libor's permission.

This is very nice catch, Nandini!

Comment 8 Nandini Chandra 2016-12-12 18:43:26 UTC
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$.

Comment 10 Šimon Lukašík 2016-12-13 21:18:32 UTC
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.

Comment 12 CFME Bot 2017-01-10 15:21:12 UTC
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(-)

Comment 13 CFME Bot 2017-01-10 15:21:17 UTC
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

Comment 15 CFME Bot 2017-01-18 16:20:50 UTC
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(-)

Comment 16 CFME Bot 2017-01-18 16:20:55 UTC
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

Comment 17 Nandini Chandra 2017-02-21 20:10:16 UTC
This issue affects 5.6.4 as well.Can this be cloned to 5.6?

Comment 18 Šimon Lukašík 2017-02-22 09:30:00 UTC
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!

Comment 21 Nandini Chandra 2017-04-13 20:07:24 UTC
Verified in 5.8.0.10