-
Notifications
You must be signed in to change notification settings - Fork 900
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't charge hours before Vm/Container/Project was created #13373
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice implementation of consumed_hours_in_interval
👍
# 2) We cannot charge for future hours (i.e. weekly report on Monday, should charge just monday) | ||
@consumed_hours_in_interval ||= begin | ||
consuption_start = [@start_time, resource.try(:created_on)].compact.max | ||
consumption_end = [Time.current, @end_time].min |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this use Time.current.utc
to ensure the time is not in the local time zone?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about this for a while. It seems the TZ does not matter in this case.
The consumption_end is just used for substraction.
This pull request is not mergeable. Please rebase and repush. |
We are gonna change code to charge only for consumption since the resource creation time. First, we need to make sure all our test subject have proper created_on timestamp.
88d3dc1
to
1317470
Compare
@miq-bot remove_label wip |
Checked commits isimluk/manageiq@e2d0561~...1317470 with ruby 2.2.5, rubocop 0.37.2, and haml-lint 0.16.1 |
Backported to Euwe via #13554 |
What
When calculating average consumption (like Mhz) we divide consumption by number of hours in the interval. However, when VM gets created in the middle of the month, we should divide only by number of hours that the resource lived. Similarly, we should charge the consumption only for the hours that the resource existed.
Why
This becomes important for SCVMM. We charge for SCVMM without metric rollups. Hence, this case have higher chances to occur with SCVMM chargebacks. (Although it affects rollup-based chargebacks as well).
Note
This pr builds on top of #13134.
@miq-bot add_label chargeback, bug
@miq-bot assign @gtanzillo