-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Allow specification of multiple expanders #4233
Allow specification of multiple expanders #4233
Conversation
Welcome @ryanmcnamara! |
fixes #4206 |
Built and deployed this locally and confirmed I was able to use |
|
||
switch expanderFlag { | ||
case expander.RandomExpanderName: | ||
filters = append(filters, random.NewFilter()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't it be an error to specify an expander that's guaranteed to provide a single option with a fallback? E.g. random,least-waste
is not really a reasonable config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True that the configuration is not a reasonable one, but I felt that catching this case wasn't worth the effort as it would require disambiguating between expanders that
- Always return one result and
- Those that can return more than one.
My thinking is that since it won't create problems then we can keep the simplicity of allowing this. Happy to be overruled on this though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's what it would look like: https://github.com/ryanmcnamara/autoscaler/compare/rm/expander-chain...ryanmcnamara:rm/expander-chain-demo?expand=1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, something like this. I'm not insisting on this one, but since you're generating an error for one class of invalid configs (duplicated entries), I thought it may make sense to go a step further and disallow bad ordering as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok addressed in this pr now!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Neat, thanks! Maybe worth adding a comment about this behavior? May be surprising for anyone adding a new expander in the future. Please also squash commits before merging.
func (c *chainStrategy) BestOption(options []expander.Option, nodeInfo map[string]*schedulerframework.NodeInfo) *expander.Option { | ||
filteredOptions := options | ||
for _, filter := range c.filters { | ||
filteredOptions = filter.BestOptions(filteredOptions, nodeInfo) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is non-trivial logic behind BestOptions call sometime, so maybe worth returning earlier if there's just one option left?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, will do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
1ad750b
to
795a8d6
Compare
Looking for a review from a code owner, perhaps @MaciekPytel or if not can you redirect? Thanks! |
I'm about to go on vacation tomorrow, so to make sure it's not blocked on me in the meantime: /lgtm For final approval: |
Just realized this is still open. Can you squash the commits? |
417d8ff
to
9214395
Compare
@x13n done! |
/lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mwielgus, ryanmcnamara 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 |
Please fix:
|
Multiple expanders can now be specified, expanders now "filter to the tied for best" instead of "selecting the best" so the output of one expander is now fed to the input of the next. Each expander may only be used once to disallow bad configuration. This should not be a change in functionality as in the event of a tie the random expander is still used.
9214395
to
068af5b
Compare
@mwielgus done, thanks for the review |
/lgtm |
The github action hooks didn't run the unit tests on the expanders update in kubernetes#4233 (likely the known "tests don't run automatically for new contributor" limitation). NewStrategy became NewFilter, with a BestOptions (plural) method, and returns a Options slice instead of a single Option.
The github action hooks didn't run the unit tests on the expanders update in kubernetes#4233 (likely the known "tests don't run automatically for new contributor" limitation). NewStrategy became NewFilter, with a BestOptions (plural) method, and returns a Options slice instead of a single Option.
The github action hooks didn't run the unit tests on the expanders update in kubernetes#4233 (likely the known "tests don't run automatically for new contributor" limitation). NewStrategy became NewFilter, with a BestOptions (plural) method, and returns a Options slice instead of a single Option.
Allow specification of multiple expanders
Allow specification of multiple expanders -- EDIT: change uses of scheduler/schedulerframework to scheduler/nodeinfo, as we are not yet on the version that switches
The github action hooks didn't run the unit tests on the expanders update in kubernetes#4233 (likely the known "tests don't run automatically for new contributor" limitation). NewStrategy became NewFilter, with a BestOptions (plural) method, and returns a Options slice instead of a single Option.
Allow specification of multiple expanders
The github action hooks didn't run the unit tests on the expanders update in kubernetes#4233 (likely the known "tests don't run automatically for new contributor" limitation). NewStrategy became NewFilter, with a BestOptions (plural) method, and returns a Options slice instead of a single Option.
Allow specification of multiple expanders
I don't want to upgrade my cluster to 1.23 but i really like this feature, You think if I upgrade the CA version to 1.23 while on a 1.20 cluster, what are the chances it'll work? |
Allow specification of multiple expanders
Allow specification of multiple expanders
The github action hooks didn't run the unit tests on the expanders update in kubernetes#4233 (likely the known "tests don't run automatically for new contributor" limitation). NewStrategy became NewFilter, with a BestOptions (plural) method, and returns a Options slice instead of a single Option.
Multiple expanders can now be specified, expanders now "filter to the
tied for best" instead of "selecting the best" so the output of one
expander is now fed to the input of the next. Each expander may only
be used once to disallow bad configuration. This should not be a change
in functionality as in the event of a tie the random expander is still
used.