Replies: 5 comments 2 replies
-
Definitely first to do is rollback. This change should have never been backported to v3.5. We can continue the discussion about changing Watch api in v3.6. |
Beta Was this translation helpful? Give feedback.
-
FYI. #14995 |
Beta Was this translation helpful? Give feedback.
-
So sorry for the trouble. I opened an issue for adding Code based member to WatchResponse: #15058 |
Beta Was this translation helpful? Give feedback.
-
@ahrtr We use etcd with auth for non-kube use-case. I got feedback that recreating client will be cumbersome. So, I'd like help contribute fix that will keep retry in the watch. Adding For wider community here are arguments why it will be useful to keep retry logic:
|
Beta Was this translation helpful? Give feedback.
-
Thanks @lavacat , the direction of adding Please feel free to work on #15058 if @mitake hasn't get started. |
Beta Was this translation helpful? Give feedback.
-
Background
In order to fix #12385, PR #14322 introduced a change in which the client side may retry based on the error message returned from server side.
This is not good, as it's too fragile and it's also changed the protocol between client and server. Please see the discussion in kubernetes/kubernetes#114403
Note: The issue #12385 only happens when auth is enabled, and client side reuse the same client to watch.
Solutions
Solution 1
Rollback the change. Reasons:
Solution 2
Add a field something like
ReasonCode
inWatchResponse
.etcd/api/etcdserverpb/rpc.pb.go
Lines 2192 to 2221 in ee9db72
Thoughts ?
Please let me know your thought.
cc @mitake @ptabor @serathius @spzala
@liggitt @dims @lavalamp @deads2k
Beta Was this translation helpful? Give feedback.
All reactions