-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
🌱 Add Node watch to Machine controller #3826
🌱 Add Node watch to Machine controller #3826
Conversation
029c28d
to
9e99cbf
Compare
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
if err := r.Client.List( | ||
context.TODO(), | ||
machineList, | ||
client.MatchingFields{clusterv1.MachineNodeNameIndex: node.Name}, |
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 didn't catch this in the 0.3 PR, but I just noticed that we're not restricting to machines in a specific namespace or for a specific cluster. We should probably do that, to avoid any possible false positives (e.g. 2 clusters in 2 different VPCs that have the same node name for a node).
func (r *MachineReconciler) nodeToMachine(namespace, clusterName string) func(o client.Object) []reconcile.Request {
return func(o client.Object) []reconcile.Request {
// use namespace and clusterName in r.Client.List
}
}
WDYT? cc @vincepri @fabriziopandini
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 makes sense, it helps with potential conflicts, although it needs to be tested if we can mix and match field matchers with normal ones
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.
You mean InNamespace + MatchingFields? Any reason to think that wouldn't work?
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.
Looking at the CacheReader implementation, it looks like:
- If there is a field selector, respect that
- Else, if there is a namespace match, use that
- Else, list everything
THEN, if there is a label selector, honor that.
So we can't do namespace + field selector 😦
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.
Maybe we should enhance this in C-R?
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.
and then
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.
Yes, this seems like it could be a good improvement there
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.
Do we want to file an issue and merge this PR as-is for now given that's just forward porting?
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.
Yes
/milestone v0.4.0 |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vincepri 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 |
What this PR does / why we need it:
Forward porting #3748