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!
|
|
||
| This proposal introduces a mechanism to configure "child channels"—channels created internally by gRPC components (such as xDS control plane channel). Currently, these internal channels cannot easily inherit configuration (like metric sinks and interceptors) from the user application without relying on global state. This design proposes a language-specific approach to injecting configuration: using `functional interfaces` in Java, `DialOptions` in Go, and `ChannelArgs` in Core. | ||
| Complex gRPC ecosystems often require the creation of auxiliary channels that | ||
| are not directly instantiated by the user application. The primary examples are: |
There was a problem hiding this comment.
In Go, the Channel passes a BuildOptions struct when creating a resolver or an LB policy. The struct is different for the two cases. But currently it contains things like credentials, dialer etc that the resolver and balancer should use if and when they are creating a Channel themselves.
We could add a new field in this struct to contain the child Channel options. As a long-term cleanup, we could deprecate some of the existing fields and move them to the newly added options field as well.
For the server, it should be simpler as the xDS-enabled server is the one that attempts to create the xDS client.
8 participants
No description provided.