-
Notifications
You must be signed in to change notification settings - Fork 39.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
[migration phase 1] Make scheduler cache, volume binder and listers available when registering default plugins #83694
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahg-g 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 |
) | ||
|
||
// DefaultRegistryArgs arguments needed to create default plugin factories. | ||
type DefaultRegistryArgs struct { |
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.
I prefer to name it to RegistryArgs
, because when declaring a DefaultRegistryArgs
variable does not really give you a default registry args by default.
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.
This is args for default registry, not default RegistryArgs, but I see how this can be interpreted the other way, I changed it as you suggested.
pkg/scheduler/scheduler.go
Outdated
time.Duration(options.bindTimeoutSeconds)*time.Second) | ||
|
||
if options.frameworkRegistry == nil { | ||
options.frameworkRegistry = frameworkplugins.NewDefaultRegistry(&frameworkplugins.DefaultRegistryArgs{ |
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.
If we create a new function(e.g. NewRegistryArgs
), we could call it from cmd/kube-scheduler/app/server.go
, then we do not need to disable out-of-tree framework plugins.
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.
that will require us to define global variables for the cache and volume binder, which is a pain to deal with. The framework is changing so fast right now there is no point in actually supporting out-of-tree plugins before beta.
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.
that will require us to define global variables for the cache and volume binder
I could not get your point why we need to define global variables for them, we could still declare them as local variables and use them as following. Is there any problem?
schedulerCache := internalcache.New(30*time.Second, stopCh)
volumeBinder := volumebinder.NewVolumeBinder(client, nodeInformer, pvcInformer, pvInformer, storageClassInformer
The framework is changing so fast right now there is no point in actually supporting out-of-tree plugins before beta.
We are trying this feature, not sure whether others are using it now. Even it is alpha, we could get feedback from users. If it is not a must, I think it might be better to keep it.
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.
that will require us to define global variables for the cache and volume binder
I could not get your point why we need to define global variables for them, we could still declare them as local variables and use them as following. Is there any problem?
schedulerCache := internalcache.New(30*time.Second, stopCh) volumeBinder := volumebinder.NewVolumeBinder(client, nodeInformer, pvcInformer, pvInformer, storageClassInformer
schedulerCache and volumeBinder are shared handlers, we can't instantiate them multiple times, they need to be created once.
The framework is changing so fast right now there is no point in actually supporting out-of-tree plugins before beta.
We are trying this feature, not sure whether others are using it now. Even it is alpha, we could get feedback from users. If it is not a must, I think it might be better to keep it.
It is going to be tricky to keep this, and it is very premature to say we support out-of-tree plugins at this stage because we are changing the framework very frequently as we discover its limitation during the migration. If you are testing this feature, I think you can still carry a small patch to enable this back in your dev environment. Is that reasonable?
cmd/kube-scheduler/app/server.go
Outdated
if len(registryOptions) != 0 { | ||
return errors.New("out-of-tree framework plugins are not yet supported") | ||
} |
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.
Instead of totally disabling it, does a warning giving the limitations sound better? If so, does it resolve @hex108 's concern?
pkg/scheduler/scheduler.go
Outdated
volumeBinder := volumebinder.NewVolumeBinder(client, nodeInformer, pvcInformer, pvInformer, storageClassInformer, | ||
time.Duration(options.bindTimeoutSeconds)*time.Second) | ||
|
||
if options.frameworkRegistry == nil { |
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.
If external users register something into frameworkRegistry
, i.e. it's not nil, IMO it's still possible for the internal scheduler to register the frameworkplugins.RegistryArgs
below? Are you concerned with some side effects? If so, we can warn users.
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.
I mean we can still give a bare frameworkRegistry
to end users to register custom things at cmd/.../app.go
, and then inject the necessary fields here (to pass to legacy predicates/priorities).
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.
I think I know how to do this. We can add an option to scheduler.New to pass a "outOfTreeRegistry", which collects out-of-tree plugins that we append to the default registry, I will send a patch to show you how it looks, thanks for brainstorming.
dd314d7
to
a8ce4ac
Compare
…actories for default plugins
/lgtm Thanks, @ahg-g ! |
/retest |
It is great! The release note also needs to be changed. :) |
[migration phase 1] Make scheduler cache, volume binder and listers available when registering default plugins
What type of PR is this?
/kind feature
What this PR does / why we need it:
Plumped handlers necessary to instantiate some predicates/priorities. This is necessary during phase 1 of framework migration.
Which issue(s) this PR fixes:
Fixes #83687