Future of GRPC-LB

121 views
Skip to first unread message

blazej...@gmail.com

unread,
Feb 22, 2019, 11:52:16 AM2/22/19
to grpc.io
What is the status of GRPCLB - are there any plans to enable it by default and finish the experimental stage (we want to start using it in production), or opposite, you plan to abandon it? I am confused, because I've read this PR: https://github.com/grpc/grpc-java/pull/5232:

SRV has not yet been enabled in a release. Since work is rapidly
underway to replace GRPC-LB with a service config+XDS-based solution,
there's now thoughts that we won't ever enable grpclb by default
(but
may allow it to be automatically enabled when using GoogleDefaultChannel
or similar). Since things are being worked out, disable it.

It will be really helpful to us to know, what is the plan for it :)

Penn (Dapeng) Zhang

unread,
Feb 22, 2019, 3:16:54 PM2/22/19
to grpc.io
Neither grpclb nor xds will be enabled by default, grpclb need be explicitly enabled by a service config or a ManagedChannelBuilder option, and xds need be explicitly enabled by a service config.  Grpclb will eventually be replaced by xds based solution in the future, but the grpc-grpclb maven artifact will stay and work for a long time (for as many new releases as possible). When grpclb is not available for a new grpc release, your client can still automatically switch to a fallback loadbalancer (pick_first).

blazej...@gmail.com

unread,
Feb 23, 2019, 3:48:43 AM2/23/19
to grpc.io
And what about SRV records lookup: now I have to set this flag:

io.grpc.internal.DnsNameResolverProvider.enable_grpclb

to true, and there was a commit some time ago which enabled it by default: https://github.com/grpc/grpc-java/commit/c729a0f76b244da9f4aebc40896b2fb891d1b5c4 and now it has been reverted: https://github.com/grpc/grpc-java/pull/5232 - how it is eventually going to be? 

Carl Mastrangelo

unread,
Feb 25, 2019, 1:19:48 PM2/25/19
to grpc.io
Like Penn said, you can turn it on (it's experimental), but will eventually be replaced.  The flag itself is pretty simple, but the rest of the machinery needs to be set up properly for it to work.  We (gRPC maintainers) are not comfortable supporting this yet, hence the extra effort to turn it on.   The gRPCLB Load Balancer is experimental, so we will likely remove it at some point.  We will give a notice in one of the upcoming releases that it is deprecated, and then remove it the release after.   Since the replacement isn't yet ready, it has not been removed.

Sorry to be so non-committal, but it seems like XDS is a better long term LB solution, and we don't want to support two competing implementations.

blazej...@gmail.com

unread,
Feb 25, 2019, 3:39:27 PM2/25/19
to grpc.io
The thing is, that we have implemented a server-side LB which speaks grpclb and this whole machinery seems to work pretty well - so we wanted to deploy it any day now. What is more, we wanted to make it open-source and we had some ideas to develop it further. So, could you be a little bit more specific on those topics?

1) How long (approximately) will grpclb be still supported? It would be fair to have some time to migrate to the new solution.
2) How will this new solution look like? I can't find any information about it, either on grpc's GitHub (no docs) or on this group. When I try to google "grpc load balancing" I still hit docs about grpclb.
3) Is this XDS solution going to work out-of-the-box, or, similarly to grpclb we will have to implement some part on our own (I mean, in grpclb we had to implement server-side of the protocol - how does it work with XDS)?

Srini Polavarapu

unread,
Feb 28, 2019, 12:58:18 AM2/28/19
to grpc.io
Please expect a post on this soon. It will have the details you are looking for but a detailed gRFC will come later. We can continue discussion on that post.

Thanks. 

Srini Polavarapu

unread,
Feb 28, 2019, 4:01:32 PM2/28/19
to grpc.io
Details are posted now.
Reply all
Reply to author
Forward
0 new messages