Don't allow excess claims to create extra CDs #1463
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 2uasimojo The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
Codecov Report
@@ Coverage Diff @@
## master #1463 +/- ##
=======================================
Coverage 41.08% 41.09%
=======================================
Files 334 334
Lines 30052 30054 +2
=======================================
+ Hits 12348 12350 +2
Misses 16658 16658
Partials 1046 1046
|
Previously, due to a math error, if the number of pending claims exceeded the pool size, we would create the surplus number of CDs, assign them, and then delete them. This commit fixes the math error: any excess claim will remain Pending until capacity becomes available to create a CD for it. **NOTE:** The above also applies to the edge case where the pool size is zero. A claim against such a pool will remain Pending *until the pool is edited to have a nonzero size*. This differs from other scenarios when we're at capacity: - If we've reached `MaxSize`, capacity becomes available when a *CD* is deleted (which may be prompted by its *claim* being deleted). - If we've reached `MaxConcurrent`, capacity becomes available when a *CD* finishes provisioning or deprovisioning. Due to this discrepancy, the argument could be made to treat a zero-size pool specially and simply fail any claim against it. We can debate that separately; this commit doesn't address it. HIVE-1593
those things make it sound like the pool is supposed to keep some warm clusters for immediate claim, but technically allow as many claims are requested.. (unless limited my other configuration) so "Don't allow excess claims to create extra CDs" kind of seems to go against the purpose? |
the delete part seem like the incorrect behavior based on the current expectations.. 🤔 |
|
To me, the documentation as written makes no indication one way or the other as to what the behavior of excess claims should be. One could make a case for either interpretation of "pool size". It's just an architectural decision we need to make. @dgoodwin care to make the call here? |
|
We decided in scrum today (20210721) that we do want to allow claims to generate CDs in excess of the pool size. The capacity is controlled by MaxSize. Closing this in favor of whatever comes out of HIVE-1599. |
Previously, due to a math error, if the number of pending claims exceeded the pool size, we would create the surplus number of CDs, assign them, and then delete them. This commit fixes the math error: any excess claim will remain Pending until capacity becomes available to create a CD for it.
NOTE:
The above also applies to the edge case where the pool size is zero. A claim against such a pool will remain Pending until the pool is edited to have a nonzero size.
This differs from other scenarios when we're at capacity:
MaxSize, capacity becomes available when a CD is deleted (which may be prompted by its claim being deleted).MaxConcurrent, capacity becomes available when a CD finishes provisioning or deprovisioning.Due to this discrepancy, the argument could be made to treat a zero-size pool specially and simply fail any claim against it. We can debate that separately; this commit doesn't address it.
HIVE-1593