[grpc-io] More granularity for errors generated by gRPC itself

Hi, Is there a chance to add details to errors generated by gRPC layer itself to distinguish different scenarios instead of forcing gRPC users to analyze error message client-side? Parsing error messages is error-prone as they are not standardized across different languages and can change over

Re: [grpc-io] Re: ALTS outside of GCP

> > Thanks, > Jiangtao > > > On Thu, Apr 19, 2018 at 4:23 PM 'Ruslan Nigmatullin' via grpc.io < > grp...@googlegroups.com > wrote: > >> Thanks for you response, >> >> Please let us know if we (Dropbox) can help in any way with this decision >> or with i

[grpc-io] Re: ALTS outside of GCP

Thanks for you response, Please let us know if we (Dropbox) can help in any way with this decision or with implementing any functionality/tests for alts to ease the process. On Friday, March 30, 2018 at 4:51:43 PM UTC-7, jian...@google.com wrote: > > So far ALTS is for GCP use only. Let me

[grpc-io] ALTS outside of GCP

Hi, We're evaluating the possibility of using ALTS instead of TLS in our internal infrastructure for visibility and performance reasons. How ALTS support is positioned from gRPC perspective? Is it GCP implementation detail or you're supporting other companies in using it? We may need to

[grpc-io] Re: ALTS outside of GCP

Hi Jiangtao, On Thursday, March 29, 2018 at 10:54:22 AM UTC-7, jian...@google.com wrote: > > Hi Ruslan, > > ALTS is not ready for public consumption yet. We could expose ALTS to > early access customers. > Thanks for clarifying, we don't have immediate plans to use ALTS in our production

[grpc-io] Connection deduplication

Hi, It looks like grpc-core performs a deduplication of TCP connections for subchannels with the same channel arguments [1]. However it doesn't look like it's a case for grpc-go implementation. It sounds like a useful behavior in the context of grpclb, as it allows reducing number of connections

Re: [grpc-io] Re: Proposal to add a new TLS credential API to support SPIFFE mutual TLS

Golang gRPC credentials API allows creating clones of the credentials and override server names. It's useful in couple of scenarios, namely grpclb and having single "original" credential object shared across all clients/servers in the process (to actually reload & parse certs once per process,

Re: [grpc-io] Re: Proposal to add a new TLS credential API to support SPIFFE mutual TLS

Hi, I've read grpc-core a bit more and it looks like I've misunderstood the interaction between resolver and authority used by TLS layer. It looks like it's resolver's responsibility to provide the correct authority for the given target (which is later going to be used for initializing secure

Re: [grpc-io] Re: Proposal to add a new TLS credential API to support SPIFFE mutual TLS

We use it in production for workload-to-workload communication. TLS certificate's CNAME contains an identity of the service and it is used for mutual authentication (so said, hostname and ip address are not directly part of the cname). We're planning to look at SPIFFE in the future and described

Re: [grpc-io] gRFC L58: Async API for gRPC Python

Using generators for streaming leads to unidiomatic python and effectively disallows service developer to control the execution flow. For example, in case of server-side bidirectional streaming it is impossible to cleanup resources once RPC is done, as execution can abort somewhere outside of the

Re: [grpc-io] gRFC L58: Async API for gRPC Python

>> For large companies, the migration will be even harder. >> It's not really effective use of time for our users to redesign their big >> project just to upgrade a framework. >> So, we want to help users get through this process smoothly, instead of >> introducing a completely incompatible