A102: xDS GrpcService Support #510
Conversation
|
CC @sergiitk |
| for this right now but could add it later if needed. | ||
| - `channel_args`: Ignored. Not supportable across languages in gRPC. | ||
| - [`timeout`](https://github.com/envoyproxy/envoy/blob/7ebdf6da0a49240778fd6fed42670157fde371db/api/envoy/config/core/v3/grpc_service.proto#L308): | ||
| If set, this will be used to set the deadline on RPCs sent to the |
There was a problem hiding this comment.
Do we have any recommendations for a default value for this timeout, when unset?
There was a problem hiding this comment.
If unset, the RPC will not have any deadline set, just like if you use the normal gRPC client API.
There was a problem hiding this comment.
I remember this coming up at some point, but my memory is vague. Do we plan to cap this timeout at the timeout value specified on the client RPC, or do we want this to be completely independent? And what if the client RPC is cancelled or times out while this is still ongoing?
There was a problem hiding this comment.
I don't remember discussing this before, but these are good questions.
Capping this based on the deadline of the data plane RPC feels a little clunky to me, for two reasons:
- From an xDS perspective, it isn't really clear what the data plane RPC's deadline is. Envoy doesn't actually have a single deadline timer the way that gRPC does; instead, it has a variety of different timeout knobs, so it's much less clear which one(s) would be used for this kind of propagation. So this behavior would probably be specific to gRPC.
- Even in gRPC, we could not do this kind of propagation in every case, because there are cases like RLQS where the side-channel RPC is a long-running stream, not directly associated with individual data plane RPCs. But we could say that we could do this on a case-by-case basis, so it would work for things like ext_authz and ext_proc, even though we wouldn't do it for RLQS.
I think for now, let's not try to do this deadline propagation. But I am open to adding it later if we need it for some reason.
The second question is comparatively easier to answer, but the answer is different in each case, similar to what I described in the second bullet above. In a case like RLQS, where the side-channel call is not associated with any one individual data plane RPC, the termination of the data plane RPC does not affect the side-channel call in any way. However, in a case like ext_authz or ext_proc, where the side-channel RPC is one-to-one with the data plane RPC, we would absolutely terminate the side-channel RPC when the data plane RPC fails. But I don't think we need to note that here, because that should be a facet of the ext_authz and ext_proc designs, not of this design.
2 participants
No description provided.