Should it be documented that xds always uses the grpc-netty-shaded transport?

[lepistone]

Hello!

While examining the dependency graph of one of our projects, I realized that while the rest of the gRPC libraries are transport-agnostic (choices being grpc-netty grpc-netty-shaded okhttp and in-process), the xds module has a runtime dependency on grpc-netty-shaded.

My guess is that this is because xds itself uses gRPC.

I suppose this means that effectively when using xds, the only sane choice is to use grpc-netty-shaded as transport in the application itself (we use grpc-netty now). Is this correct? Should it be documented?

Thank you!

[sanjaypujare]

Correct. Pls see this comment .

Pls suggest where this should be documented.

[lepistone]

Thank you! Here's a suggestion: #7877.

[sanjaypujare]

Sounds good. Will take a look.

[ejona86]

I don't think the xds module is strictly limited to grpc-netty-shaded. When contacting Google's Traffic Director it uses GoogleDefaultChannelCredentials which are limited to grpc-netty-shaded, for the control plane connection. Also, the new security integration with xDS will require grpc-netty-shaded, for the backend connection.

[sanjaypujare]

I don't think the xds module is strictly limited to grpc-netty-shaded. When contacting Google's Traffic Director it uses GoogleDefaultChannelCredentials which are limited to grpc-netty-shaded, for the control plane connection. Also, the new security integration with xDS will require grpc-netty-shaded, for the backend connection.

So wouldn't it be a good idea to say that grpc-netty-shaded is recommended if you are using grpc-xds for all the reasons you mentioned plus the issue?

[ejona86]

@sanjaypujare, did you really mean to link to #7534 ? Only a small percentage of our users are using GraalVM, and that issue was a configuration issue; I don't think it impacts this discussion at all.

I didn't mention "reasons to use grpc-netty-shaded." We can document "XdsChannelCredential/XdsServerCredential is only compatible with grpc-netty-shaded; grpc-netty-shaded is auto-selected when using the io.grpc.Grpc API." The GoogleDefaultChannelCredentials piece still allows you to use grpc-netty for your channel, but the channel to the control plane will still be grpc-netty-shaded. That has always been a limitation of GoogleDefaultChannelCredentials, but whether we use those credentials is determined by the bootstrap.

[sanjaypujare]

@sanjaypujare, did you really mean to link to #7534 ? Only a small percentage of our users are using GraalVM, and that issue was a configuration issue; I don't think it impacts this discussion at all.

It was this comment in the issue I was trying to highlight. I guess that comment still applies even though it doesn't involve GraalVM?

I didn't mention "reasons to use grpc-netty-shaded." We can document "XdsChannelCredential/XdsServerCredential is only compatible with grpc-netty-shaded; grpc-netty-shaded is auto-selected when using the io.grpc.Grpc API." The GoogleDefaultChannelCredentials piece still allows you to use grpc-netty for your channel, but the channel to the control plane will still be grpc-netty-shaded. That has always been a limitation of GoogleDefaultChannelCredentials, but whether we use those credentials is determined by the bootstrap.

So it would be okay to say "using grpc-netty-shaded is recommended" if you are using xDS considering all this?

[ejona86]

It was this comment in the issue I was trying to highlight.

What part of that comment? The comment references io.grpc.NameResolverRegistry.getHardCodedClasses, which is actually wrong. getHardCodedClasses is only used on Android. On non-Android we use ServiceLoader which loads files from META-INF/services. I'm not aware of any issues using shaded and non-shaded together. If there are issues, we need an issue filed and we need to fix it.

So it would be okay to say "using grpc-netty-shaded is recommended" if you are using xDS considering all this?

We always recommend grpc-netty-shaded over grpc-netty, even outside xds. But if someone needs grpc-netty that's fine. The xds credentials require grpc-netty-shaded, which can be important to point out.

Technically it is possible to lift the grpc-netty-shaded restriction if there was enough of a need, although it would take care.

[sanjaypujare]

What part of that comment? The comment references io.grpc.NameResolverRegistry.getHardCodedClasses, which is actually wrong. getHardCodedClasses is only used on Android. On non-Android we use ServiceLoader which loads files from META-INF/services. I'm not aware of any issues using shaded and non-shaded together. If there are issues, we need an issue filed and we need to fix it.

Oh, okay - I missed that. So that issue is not relevant here.

So it would be okay to say "using grpc-netty-shaded is recommended" if you are using xDS considering all this?

We always recommend grpc-netty-shaded over grpc-netty, even outside xds. But if someone needs grpc-netty that's fine. The xds credentials require grpc-netty-shaded, which can be important to point out.

Technically it is possible to lift the grpc-netty-shaded restriction if there was enough of a need, although it would take care.

So the only thing really left to do is what to do with this PR #7877. You can add comments there to get the exact desired wording for grpc-netty-shaded.

[lepistone]

OK, I finally got to resolving the small comments on #7877. If that looks OK and I understand the discussion above, we should be able to resolve this. Thank you!