A110: Child Channel Options#529
Conversation
markdroth
left a comment
markdroth
left a comment
There was a problem hiding this comment.
The overall design looks good, but I think the doc needs work.
My main concern is that we need a much better description of the overall design in a language-agnostic way, rather than just saying that we have a different design for each language. It's true that each language has its own APIs for how per-channel options are set, but the overall goal here is still to have a way to pass a set of options to be used in child channels. The semantics for that should be the same in all languages.
Please let me know if you have any questions. Thanks!
markdroth
left a comment
markdroth
left a comment
There was a problem hiding this comment.
This is looking much better!
Please let me know if you have any questions. Thanks!
…g to make it clear
| 1. xDS: When a user creates a channel with an xDS target, the gRPC library | ||
| internally creates a separate channel to communicate with the xDS control | ||
| plane. |
There was a problem hiding this comment.
The XdsClient has the ability to create gRPC channels to multiple xDS management servers (as part of the support we added for federation). In Go (and I believe in C++), these gRPC channels are created lazily, i.e., at the time when a resource needs to be requested from management A, a gRPC channel is created to it.
Now, how does this work when we have multiple parent channels. Will the child options of the first parent channel, P1, that creates the XdsClient be applied to all child channels (even though P1 might not have anything to do with a child channel that was created when another parent channel P2 requested a resource from a different management server).
There was a problem hiding this comment.
I think this was addressed at https://github.com/grpc/proposal/pull/529/changes#diff-8a3140e3e8002e31a20d2188875d3f70478ae6a195a4bbb7a48ebedd604ced90R90-R105. Do let me know if u meant something else.
There was a problem hiding this comment.
I had seen that. But I felt it didn't quite address the nuance involved with the XdsClient in the sense that it can create multiple child channels, and not all of them are created at the same time and not all of them as a result of resource watches created by a single parent.
There was a problem hiding this comment.
I think the behavior we'd want here is to pass the child channel options to the XdsClient when the XdsClient is created, and then that XdsClient instance will use those same child channel options for any child channel it creates over the lifetime of the XdsClient.
I don't see any other way this could reasonably work, because after the XdsClient is created, there's no other place where we'd pass down channel options to use from a "parent" channel.
markdroth
left a comment
markdroth
left a comment
There was a problem hiding this comment.
Just one small remaining comment, otherwise looks great!
|
|
||
| * Java: The `Helper` will provide a function that accepts a `ChannelBuilder` and applies the child channel options to it. | ||
| * Go: A new field will be added to the `BuildOptions` struct (passed when creating a resolver or LB policy) to contain the child channel options. | ||
| * C-core: No special plumbing is needed because the child channel args are simply passed as channel arguments, which are already available to LB policies. |
There was a problem hiding this comment.
We should also say that the LB policy will need to propagate both the individual child channel args and the arg containing the child channel args to the child channel.
| 1. xDS: When a user creates a channel with an xDS target, the gRPC library | ||
| internally creates a separate channel to communicate with the xDS control | ||
| plane. |
There was a problem hiding this comment.
I think the behavior we'd want here is to pass the child channel options to the XdsClient when the XdsClient is created, and then that XdsClient instance will use those same child channel options for any child channel it creates over the lifetime of the XdsClient.
I don't see any other way this could reasonably work, because after the XdsClient is created, there's no other place where we'd pass down channel options to use from a "parent" channel.
8 participants
No description provided.