Watch keepalive not working anymore with 1.0.0 #2127
Comments
|
My guess is that the fix from the v0.x branch just never made it to the v1.x branch. Does applying the fix from #630 fix the issue for you locally? If it does fix the issue, I also wonder if we even need the |
|
|
|
Ah, ok. We do support Agents in the new version. This call returns an object containing an agent (created in |
|
Actually, in 0.22.2, So I guess, we need to access the socket and apply the same options, I will try to do a PR. |
These features were present prior to the 1.0 refactor but were inadvertently removed. See kubernetes-client#2127
This will send sends keep-alive probes to the server every 30 seconds. These features were present prior to the 1.0 refactor but were inadvertently removed. Fixes kubernetes-client#2127 Previous relevant issues: - Initial issue: kubernetes-client#559 - PR: kubernetes-client#630 - Improvement: kubernetes-client#632 - PR: kubernetes-client#635
This will send sends keep-alive probes to the server every 30 seconds. These features were present prior to the 1.0 refactor but were inadvertently removed. Fixes kubernetes-client#2127 Previous relevant issues: - Initial issue: kubernetes-client#559 - PR: kubernetes-client#630 - Improvement: kubernetes-client#632 - PR: kubernetes-client#635
Describe the bug
With the version 1.0.0, when a
watchrequest is made and the connection drop, no more events are reported, but there is also no error that indicate that the connection was dropped. (I waited 10 minutes to be sure)With version 0.22.2, under ~33s, I got the error
read ETIMEDOUT, allowing me to retry the connection and restart the watch request.This issue was already raised on #559 and fixed with PR #630. This PR add a config to configure keepalive packets in
watch.ts, but I don't see this config on the version 1.0.0.Client Version
1.0.0(but working on 0.22.2)Server Version
1.30.3To Reproduce
In my case, I start the
watch-example.tsand then cut the VPN connection to my cluster. As it's related to network perturbation, it's not easy to suggest an easy reproducible way to do it. I guess you can also use your firewall to drop packets in the middle of a watch request.Expected behavior
I expect an error to be thrown when the Kubernetes api becomes unavailable while a watch request is running like it was the case for previous versions.
** Example Code**
I used the
watch-example.tsEnvironment (please complete the following information):
The text was updated successfully, but these errors were encountered: