ClusterPool: running clusters for excess claims #1567
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In openshift#1434, we added the paradigm of keeping some number of ClusterPool clusters in Running state, so they don't have to suffer Resuming time when claimed. However, that work was narrowly focussed on conforming to the ClusterPool.Spec.RunningCount. This commit expands the concept to try to make sure we're always running enough clusters to satisfy claims. In particular, when we are servicing a number of claims in excess of the pool's capacity, we create that excess number of clusters... but we previously didn't account for that number when calculating how many should be Running. Now we do. To explain via a corner case: If your pool has a zero Size and you create a claim, we will create a cluster and immediately assign it. But because RunningCount is zero, prior to this commit, we would create the cluster with `PowerState=Hibernating`, and then kick it over to `Running` when we assigned the claim. Now we'll create it with `PowerState=Running` in the first place. HIVE-1651
Member
Author
|
/assign @joelddiaz |
openshift-ci
bot
added
the
approved
Codecov Report
@@ Coverage Diff @@
## master #1567 +/- ##
=======================================
Coverage 41.86% 41.87%
=======================================
Files 336 336
Lines 30884 30887 +3
=======================================
+ Hits 12931 12934 +3
Misses 16864 16864
Partials 1089 1089
|
Member
Author
|
/test e2e |
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 2uasimojo, joelddiaz The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
|
/retest-required Please review the full test history for this PR and help us cut down flakes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #1434, we added the paradigm of keeping some number of ClusterPool
clusters in Running state, so they don't have to suffer Resuming time
when claimed. However, that work was narrowly focussed on conforming to
the ClusterPool.Spec.RunningCount.
This commit expands the concept to try to make sure we're always running
enough clusters to satisfy claims. In particular, when we are servicing
a number of claims in excess of the pool's capacity, we create that
excess number of clusters... but we previously didn't account for that
number when calculating how many should be Running.
Now we do.
To explain via a corner case: If your pool has a zero Size and you
create a claim, we will create a cluster and immediately assign it. But
because RunningCount is zero, prior to this commit, we would create the
cluster with
PowerState=Hibernating, and then kick it over toRunningwhen we assigned the claim. Now we'll create it withPowerState=Runningin the first place.HIVE-1651