clientv3: use grpc balancer #5583
Conversation
|
Maybe rebase the grpc dep with your fix grpc/grpc-go#717? Just got merged. |
| "google.golang.org/grpc" | ||
| ) | ||
|
|
||
| type balancer struct { |
There was a problem hiding this comment.
any reason for not using the default roundrobin balancer provided by grpc?
There was a problem hiding this comment.
using the grpc roundrobin balancer would just as complicated (or more so) since it needs resolver and watcher interface implementations
|
LGTM after fixing tests. |
|
So LGTM. /cc @purpleidea @siddontang regarding the issue #5495. |
|
@gyuho yes. It probably didn't belong in rpctypes in the first place since the error isn't transmitted from the server. |
heyitsanthony
force-pushed
the
grpc-nuke-waitstate
branch
4 times, most recently
from
deba127
to
70f642d
Compare
Tests need to disconnect the network connection for the client to check reconnection paths but closing a grpc connection closes the logical connection. To disconnect the client, instead have a bridge between the server and the client which can monitor and reset connections.
heyitsanthony
force-pushed
the
grpc-nuke-waitstate
branch
2 times, most recently
from
0be40af
to
6b13c7f
Compare
heyitsanthony
force-pushed
the
grpc-nuke-waitstate
branch
3 times, most recently
from
782283b
to
810f11c
Compare
heyitsanthony
force-pushed
the
grpc-nuke-waitstate
branch
from
810f11c
to
4a13c9f
Compare
|
There are virtually no commit messages or docs associated with this that I can find. Is there a short summary somewhere that we can read to learn more? Thanks! |
|
On Wed, Jun 8, 2016 at 11:09 PM, Xiang Li notifications@github.com wrote:
I just don't understand what the implications for etcd are, sorry. |
|
@purpleidea the motivation was so that |
|
@heyitsanthony Gahhh! Sounds like #5491 ... I wish I knew this was coming, great feature, but I've just spent three or so days fixing my code so that it can handle this scenario! Oh well glad to know this is coming. I have a bunch of code that depends on it if you'd like to test your new API for this before it goes mainstream. I hope it includes dealing with the change when an endpoint crashes or is fenced somehow. As an aside: where is the best place to learn about all these new and planned changes. Is there a mailing list where it's discussed or is it internal only chats? It would probably save me and other developers time to know what's going on. Cheers! |
|
@purpleidea https://github.com/coreos/etcd/milestones has the planning. It's difficult to capture everything to the last detail though. |
|
On Wed, Jun 8, 2016 at 11:46 PM, Anthony Romano notifications@github.com
This is somewhat useful, thanks! I am interested in the big picture ideas, |
No description provided.