-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Fix data race in discovery filter #51048
Conversation
/retest-required |
// No need to notify handlers for deletes | ||
f.namespaceDeleted(ns.ObjectMeta) | ||
f.lock.Lock() | ||
defer f.lock.Unlock() |
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, I think this is the critical fix.
But what is the target for updating pkg/kube/kclient/client.go
// namespaceDeleted : if deleted namespace was a member, remove it | ||
func (d *discoveryNamespacesFilter) namespaceDeleted(ns metav1.ObjectMeta) (membershipChanged bool) { | ||
// namespaceDeletedLocked : if deleted namespace was a member, remove it | ||
func (d *discoveryNamespacesFilter) namespaceDeletedLocked(ns metav1.ObjectMeta) { |
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.
nit: we donot need this function or move the lock here
} | ||
} | ||
// Removes are currently NOT handled. We only have the namespace name here. We would need to have the object | ||
// filter passthrough the entire namespace object, so we can pass the last known state to OnDelete. | ||
// Fortunately, missing a namespace delete event usually doesn't matter since everything in the namespace gets torn down. |
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.
Does this mean there is no namespace delete triggered? I think this is not right, this package can be used by not only istiod, but also other thirdparty 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.
That is the state even before this PR. Istio packages are not intended for usage outside istio so I don't really care much about the 3p use case?
We can make it send deletes consistently but it's extremely hard to do so. The problem is the filter and the namespace handler ordering is random (from informer) so we cannot guarantee the order. I don't think the complexity is worth it imo.
Either way IMO we could merge this even if we want to do this eventually, as it is strictly fixing the bug -- the missing deletes was already present
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.
Agreed, but better to improve. I have know many projects import istio libs
In response to a cherrypick label: #51048 failed to apply on top of branch "release-1.21":
|
In response to a cherrypick label: new issue created for failed cherrypick: #51115 |
In response to a cherrypick label: new pull request created: #51116 |
(cherry picked from commit 9bf6c0d)
Example crash https://prow.istio.io/view/gs/istio-prow/logs/integ-k8s-126_istio_postsubmit/1790453700397895680