No canonical URI scheme leads to severe bugs in many GRPC projects (reopens #2314)

[Ben Berman]

Every project that connects to a GRPC endpoint has a poorly specified, inconsistent half baked way of specifying the TLS (or not TLS) parameters of a GRPC client connection:

• Apache Arrow: https://github.com/apache/arrow/issues/35080
• Jaeger https://github.com/jaegertracing/jaeger/issues/3351
• Thanos: https://github.com/thanos-io/thanos/issues/977
• Keda: https://github.com/kedacore/keda/issues/3565
• Confidential Containers: https://github.com/confidential-containers/attestation-agent/issues/36
• Pravega https://github.com/pravega/pravega/issues/3895

These were just going through the first 3 pages of issues regarding "grpc tls uri" https://github.com/search?q=uri+tls+grpc . I'm sure you'll find with every GRPC based product meant for developer usage, there is an issue related to expressing how to connect to a GRPC server. Maybe all projects, thousands, with any meaningful adoption are affected by the lack of a canonical URI format.

Since I've been personally blocked by the Thanos and Keda bugs, I'm hoping that the GRPC team can adopt and advocate for a single canonical URI format that supports some of the following scenarios:

•  should we connect with TLS or not?
•  what certificate should we use to do that? it sometimes has to rotate, and it is sometimes not trusted by the executing process's root store.
•  when this address is a dns+srv address or similar load balancing expression, how should that be dealt with?

What can be done? First accept it was a mistake to not author a canonical URI format that deals with TLS well. This revisits https://github.com/grpc/grpc/issues/2314 https://github.com/grpc/grpc/pull/2758 .

In my experience in issues like these, where an architectural or design mistake was made, there will be a lot of inertia. See this far smaller bug with eksctl as an example - it still took about 3 months to change two validation lines.

That said, nobody could have anticipated that Lets Encrypt would be so widely adopted.

I'm posting this in the community here to show there will be a consensus that the lack of a canonical URI format expressing TLS settings is an issue everywhere, a hair on fire issue, and it's really making the GRPC ecosystem crummy in a way that ordinary REST users basically never deal with.

Databases have complex URI formats. This is maybe just how it goes. Maybe this is also a chance to investigate other GRPC connectivity options being put into the URI, like enabling keepalive, that are more or less application agnostic.