Allow assigning resources to nodes with finite negative scores#3802
Open
kgaillot wants to merge 10 commits intoClusterLabs:mainfrom
Open
Allow assigning resources to nodes with finite negative scores#3802kgaillot wants to merge 10 commits intoClusterLabs:mainfrom
kgaillot wants to merge 10 commits intoClusterLabs:mainfrom
Conversation
added 9 commits
January 14, 2025 17:33
... in pcmk__node_available(), to make it easier to add new conditions. I went through the callers to see if any others should reject guest nodes with unrunnable guests, and it appears not.
... now that the "alive" and "usable" checks are separated
... to isolate the code more logically
... to isolate the code more logically
Nothing uses it yet
This allows resources to be active in cases where they would previously be stopped. Fixes T335
Now that resources may be assigned to nodes with finite negative scores, two scheduler regression tests have improvements: In systemhealthp2, the stonith resource may now start, whereas before it was left stopped. There are two nodes, hs21c (with health status yellow, equivalent to -100 preference) and hs21d (which is unseen, so unclean and offline). There was no good reason to leave stonith stopped. In node-maintenance-1, rsc1 stays active where it is, whereas before it was stopped. rsc1 is started on node1 (where it has a -1 location preference), and rsc2 is started on node2 (where it has a -1 location preference), and node2 is unmanaged. Since node2 is unmanaged, rsc2 can't be moved away from it, and rsc1 has nowhere to move to even though it has a negative preference for its current node. Previously, rsc1 would be stopped even though it couldn't be recovered elsewhere.
All existing callers retain the same behavior
Author
|
@nrwahl2 , could you review this? Thanks This was something I had started but had to put aside for higher priority stuff. I went back and finished it but it needs careful consideration and review. It's a pretty big behavioral change but it can be considered a fix. |
Previously, clone children were sorted in pcmk__clone_create_probe(). However, the sort was only necessary when probing anonymous clones on nodes that wouldn't have an active instance, so now they are sorted only in that case, for a slight efficiency gain.
Author
|
The last commit is unrelated. I only glanced over the regression test changes but they appear to just be sorting differences as expected. Since the clone children are in a list, not a hash table, I expect the unsorted order to remain consistent so that regression test results don't vary, but if that does happen, this is the likely culprit. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
No description provided.