-
Notifications
You must be signed in to change notification settings - Fork 215
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
feat: add in cloudprovider disruption methods #1577
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: njtran 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 |
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 feel like this is a good time to do a code simplification on the way that we pull disruption reasons from CloudProviders with the way that we evaluate Drift
return Command{}, scheduling.Results{}, nil | ||
} | ||
|
||
func (cp *CloudProvider) Reason() v1.DisruptionReason { |
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.
Why not just use the actual reason that was passed by the CloudProvider?
|
||
// CloudProvider is a subreconciler that deletes candidates according to cloud provider specific reasons. | ||
// This should be methods that are | ||
type CloudProvider 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'm not convinced that we need a separate method definition here. Can't we just combine this with the drift implementation so that drift is just another one of these "reasons" that we pull from the CloudProvider. I'm asking because this looks exactly the same as the drift implementation at this point.
@@ -79,6 +79,8 @@ func NewController(clk clock.Clock, kubeClient client.Client, provisioner *provi | |||
cloudProvider: cp, | |||
lastRun: map[string]time.Time{}, | |||
methods: []Method{ | |||
// Terminate any NodeClaims with StatusConditions specific to the CloudProvider implementation. For | |||
NewCloudProvider(kubeClient, cluster, c.cloudProvider, recorder, provisioner), |
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.
What about appending NewStatusConditionDisruption()
with new methods gen-ed based on a combination of the CloudProvider reason and the Drift reason?
/close in favor of #1588 |
PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/close |
@jonathan-innis: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Fixes #N/A
Description
Adds in cloudprovider disruption methods - Will be taken over by @engedaam
TODO: add testing for cloudprovider methods. Either requires removing the CRD enum, or adding in the enum for each cloud provider installation, and ingesting a new CRD for the test environment
How was this change tested?
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.