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
client-go: support Shutdown()
for metadata and dynamic informers
#114434
client-go: support Shutdown()
for metadata and dynamic informers
#114434
Conversation
Followup to kubernetes#112200, specifically kubernetes#112200 (comment).
cc @pohly |
/triage accepted |
@@ -27,6 +27,7 @@ type SharedInformerFactory interface { | |||
Start(stopCh <-chan struct{}) | |||
ForResource(gvr schema.GroupVersionResource) informers.GenericInformer | |||
WaitForCacheSync(stopCh <-chan struct{}) map[schema.GroupVersionResource]bool | |||
Shutdown() |
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.
naive by-stander question, why do we need a shutdown when starts already takes a stopCh
?
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.
The shutdown additionally actually waits for everything to terminate is the difference
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.
It would make sense to copy the documentation from https://github.com/kubernetes/kubernetes/pull/112200/files, then someone (like @apelisse) who looks at this interface can see how to use it without having to know that some other, similar interface elsewhere explains 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.
Done, copy+pasted from your PR. thanks
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 super excited about this API, one needs to keep two handles to shutdown a factory (the stopCh, AND the factory which is error-prone and smelly). I can also call shutdown on something that hasn't been created. I can shutdown but forget to close the channel (it will hang forever?)
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 had called the new function WaitForShutdown
initially and then there were concerns about that name that led to a renaming 🤷
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 "RejectNewAndWaitForShutdown" at least captures what it actually does :(
Apologies for not spending more time on that review :(
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.
Normally we call the method "Run" instead of "Start" and you just wait for it to exit.
I agree that the most consistent thing to do here would be to expose a Run
which blocks. Start
could be refactored to call Run
for backwards compatibility. Is that something people are interested in?
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.
Alex, defining a Run
sounds good to me. It's not clear without digging in if it is good to make one function call the other or not.
We should definitely leave the existing Start
functions as-is behavior-wise to not break people.
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.
Yeah, I think we can define Run to call Start and the now DOA Shutdown, that'd be a good API with minimal change.
/retest |
/retest |
/retest |
Given #114496 is closed can we move forward with this for consistency? |
since this is the direction we are going for this API, this is looks good to me. I checked the changes against the original, and they are mirrored /lgtm |
LGTM label has been added. Git tree hash: 5e03ccac06ade04754f48cb0bf5388bc4bc4d3c4
|
staging/src/k8s.io/client-go/dynamic/dynamicinformer/informer.go
Outdated
Show resolved
Hide resolved
staging/src/k8s.io/client-go/metadata/metadatainformer/informer.go
Outdated
Show resolved
Hide resolved
/approve for nits: |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: howardjohn, lavalamp 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 |
/hold cancel |
/label tide/merge-method-squash |
LGTM label has been added. Git tree hash: 1c72024159e4b60f5c53439f1d3f6121b8ed4d3a
|
The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass. This bot retests PRs for certain kubernetes repos according to the following rules:
You can:
/retest |
1 similar comment
The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass. This bot retests PRs for certain kubernetes repos according to the following rules:
You can:
/retest |
…ubernetes#114434) * client-go: support `Shutdown()` for metadata and dynamic informers Followup to kubernetes#112200, specifically kubernetes#112200 (comment). * add comments * Defer lock
What type of PR is this?
/kind feature
What this PR does / why we need it:
Followup to #112200, specifically #112200 (comment).
Special notes for your reviewer:
Does this PR introduce a user-facing change?