-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Two SharedInformer issues related to kube-apiserver unavailable and relisting #1961
Comments
kolorful
changed the title
Two SharedInformer relist issues
Two SharedInformer issues related to kube-apiserver outage and relisting
Jan 22, 2020
kolorful
changed the title
Two SharedInformer issues related to kube-apiserver outage and relisting
Two SharedInformer issues related to kube-apiserver unavailable and relisting
Jan 22, 2020
@kolorful : Hi, I've started working on this issue. Could you please share an example of a stop channel to the informer in go client you mentioned in last paragraph? I think it will be a good addition and I can try integrating it alongwith fixing these two bugs. |
Thank you @rohanKanojia, here is an example from sample-controller. |
rohanKanojia
added a commit
to rohanKanojia/kubernetes-client
that referenced
this issue
Feb 15, 2020
…er unavailable and relisting + relist when 410 is received + set HasSynced() to false when Reflector faces error
rohanKanojia
added a commit
to rohanKanojia/kubernetes-client
that referenced
this issue
Feb 27, 2020
…er unavailable and relisting + relist when 410 is received + set HasSynced() to false when Reflector faces error
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Previous discussed in #1943
I encountered two issues related to shared informer (v4.7.0) when conducting destructive testing on our Kubernetes cluster.
Is it possible to let shared informer detect such issue and start a re-list right away?
On the other hand, the error seems like it falls into a wrong if condition block.
The error comes from this line:
kubernetes-client/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/dsl/internal/WatchConnectionManager.java
Line 279 in b595e42
I think it somehow mistaken Status as CRD and fall into the wrong logic block.
kubernetes-client/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/dsl/internal/WatchConnectionManager.java
Line 259 in b595e42
How to reproduce:
What I expect: re-list should fail due to kube-apiserver unavailable and hasSynced() returns false.
What actually happens: hasSynced() keep returning true without the cache being updated and client has no way to catch this error and restart the informers.
Is this expected behaviour? It seems like in client-go you can pass a stop channel to the informer and if anything went wrong client can catch that and try restarting the informers, but we don't have that ability in java yet.
The text was updated successfully, but these errors were encountered: