Implement support for excluding time intervals during an invoicing period

[knikolla]

Example, do not charge for storage during the MGHPCC shutdown.

[QuanMPhm]

@knikolla To clarify, you want to add an option in calculate_storage_gb_hours.py that allows us to exclude any arbitrary time interval from billing, such that storage usage within those time periods will not be billed? If that's the case, what is the granularity of the time interval? Days? Hours?

[knikolla]

@knikolla To clarify, you want to add an option in calculate_storage_gb_hours.py that allows us to exclude any arbitrary time interval from billing, such that storage usage within those time periods will not be billed? If that's the case, what is the granularity of the time interval? Days? Hours?

@QuanMPhm Correct. The granularity is days.

[QuanMPhm]

@knikolla I was reviewing the storage billing code, and was confused by this line. I'm not sure of the intention...

If we're filtering for change requests that happen both before the current value-change and the PREVIOUS value-change, would the following if clause always fail?

A smaller question I have is: Are we assuming that an allocation will not be denied and/or activated more than once in its lifetime? Meaning allocations will always have ONE continuous time period where it is active?

Aside from these, I understand the billing code, and will begin working on the solution once you answer my questions.

[QuanMPhm]

@knikolla @joachimweyl After reviewing the test cases, I believe that the code I mentioned above led to unintended billing behavior?

[knikolla]

@knikolla I was reviewing the storage billing code, and was confused by this line. I'm not sure of the intention...

If we're filtering for change requests that happen both before the current value-change and the PREVIOUS value-change, would the following if clause always fail?

A smaller question I have is: Are we assuming that an allocation will not be denied and/or activated more than once in its lifetime? Meaning allocations will always have ONE continuous time period where it is active?

Aside from these, I understand the billing code, and will begin working on the solution once you answer my questions.

@QuanMPhm I couldn't remember why either. You can look at the git blame of a particular line to find the corresponding commit that introduced it.

In this case f5382fb

Does that help you?

[joachimweyl]

@knikolla @joachimweyl After reviewing the test cases, I believe that the code I mentioned above led to unintended billing behavior?

@QuanMPhm thank you for the heads up. Do you have a clear path to resolve the issue?

[QuanMPhm]

@joachimweyl I'll submit a PR that surfaces this bug, and we can consider next steps once we confirm the bug and its potential impact.