-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
pass in stopCh to cloud provider Initialize method for custom controllers #70038
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -42,8 +42,9 @@ type ControllerClientBuilder interface { | |
// Interface is an abstract, pluggable interface for cloud providers. | ||
type Interface interface { | ||
// Initialize provides the cloud with a kubernetes client builder and may spawn goroutines | ||
// to perform housekeeping activities within the cloud provider. | ||
Initialize(clientBuilder ControllerClientBuilder) | ||
// to perform housekeeping or run custom controllers specific to the cloud provider. | ||
// Any tasks started here should be cleaned up when the stop channel closes. | ||
Initialize(clientBuilder ControllerClientBuilder, stop <-chan struct{}) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This breaks go compatibility, is that OK? I think it won't be OK once there's out of tree implementors? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a discussion we (SIG Cloud Provider) are having right now. There are some differing opinions around if breaking the interface is okay as long as the behaviour is not changed. In my opinion at least, this is fine because the SIG that defines the interface works closely with the implementors and we can form consensus on breaking changes like this one before moving forward. But you are correct in that we should have a definitive answer for this when we have stable out-of-tree providers. For now we are incrementally trying to put the interface at a better spot while we are still "beta" so breaking changes like this are OK in my opinion (but feel free to disagree). |
||
// LoadBalancer returns a balancer interface. Also returns true if the interface is supported, false otherwise. | ||
LoadBalancer() (LoadBalancer, bool) | ||
// Instances returns an instances interface. Also returns true if the interface is supported, false otherwise. | ||
|
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.
Wondering if it would be good to make this change in a separate PR. I believe we have other such fixes which need to be made. Might be better to not conflate the Interface change with actual fixes which may have unexpected side effects.
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 can at least do separate commit
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, PTAL :)
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.
Looks good. I think there is no way the other change will need to be rolled back. This change is unlikely but possible. Was thinking it might be good (optional) to make them separate PRs on the off change this change needed to be rolled back.