Skip to content
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

Fixed billing with decreasing allocation change requests #171

Merged
merged 2 commits into from
Aug 2, 2024

Conversation

QuanMPhm
Copy link
Contributor

Closes #170. I have introduced 3 test cases for storage billing with change requests (CR), 2 of which are intended to fail. The 3 test cases are:

  1. Testing when there is a CR to decrease the quota
  2. A CR to increase the quota
  3. Multiple CRs to decrease the quota

The test cases involving decreasing the quota should fail, and demonstrates the bug that I will explain below.

From what I read in the billing code, our intention with CRs is that when an allocation's storage quota decreases, this decreased value becomes effective (for billing purposes) when the CR for it is created, not when the CR is approved (or the time at which the quota actually decreased). Due to this statement, this will not happen, but will lead to a more complicated undesired behavior.

With the current code, the first time the quota decreases, the decreased value becomes effective at the time it is changed. On subsequent instances when the quota decreases, one of two things could happen:

  • If the quota is decreased to the same value again, the decreased quota becomes effective from the previous time the quota changed (i.e If the quota was 10GB on May 1st and 5GB on May 10th, the period from May 1st to May 10th would be billed at 5GB)
  • Else, the decreased quota becomes effective at time of change.

@knikolla
Copy link
Collaborator

Great work on catching this and apologies for the error in logic! The PR description does match the issue and the effects.

The below conditional should be flipped to cr_created_at < unbounded_last_event_time and changing that makes the tests pass correctly.

if unbounded_last_event_time and unbounded_last_event_time < cr_created_at:

Can you add a new commit to this PR that introduces the fix and removes the expectedFailure.

@QuanMPhm
Copy link
Contributor Author

QuanMPhm commented Aug 1, 2024

@knikolla I've pushed up the bug fix.

@knikolla
Copy link
Collaborator

knikolla commented Aug 1, 2024

@QuanMPhm Thanks, I'll review. If #173 passes checks, I'll merge it quickly so you can rebase your work on top of that.

@knikolla knikolla changed the title Added test cases to ensure correct billing with allocation change requests Fixed billing with decreasing allocation change requests Aug 1, 2024
Due to an boolean statement, the SU hours for storage will not
be correctly calculated when change requests (CRs) to quotas are involved.

Our intention with CRs is that when an allocation's storage quota
decreases, this decreased value becomes effective (for billing purposes)
when the CR for it is created, not when the CR is
approved (or the time at which the quota actually decreased).
The aforementioned boolean statement would instead lead to undesired behavior.
Copy link
Contributor

@naved001 naved001 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good, just a question because I don't understand the math involved.

@knikolla knikolla merged commit 07afcf0 into nerc-project:main Aug 2, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Storge billing is incorrect when quotas are changed by Coldfront change requests
3 participants