Conversation
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!
| // TODO(AgraVator): add example for configuring child channel observability | ||
| ``` | ||
|
|
||
| ## Rationale |
There was a problem hiding this comment.
We need to say somewhere that we are not trying to provide any identity information about which channel is being created. The configuration provided by this gRFC is required to be uniform across child channels of a particular channel.
There was a problem hiding this comment.
Are we sure this should be a non-goal? E.g. we might have xds client connections needing a different set of options from RLS connections/etc. It seems pretty plausible given that one team will own the control plane, but a different team would own the ext_proc services, so different credentials might be needed or different telemetry configuration may be desired.
This doesn't have to be hard; it could be a simple map from name->config.
There was a problem hiding this comment.
This is not for credentials. Both of those channels would send telemetry to the same destination (configured here), so they'd use the same credentials. We would solve multi-ownership problems by allowing applying telemetry multiple times, a different time for each consumer/configuration.
I don't disagree that someone may want to identify the purpose of the child channel, but that then means we need some way to identify the purpose of the child channel. That's a bigger lift and opens up lots of complexities on how you will categorize the child channels' purposes. In our TL discussion about it, nobody could come up with a strong need for the info, we so left it for future work if/when it is needed.
| // TODO(AgraVator): add example for configuring child channel observability | ||
| ``` | ||
|
|
||
| ## Rationale |
There was a problem hiding this comment.
This is not for credentials. Both of those channels would send telemetry to the same destination (configured here), so they'd use the same credentials. We would solve multi-ownership problems by allowing applying telemetry multiple times, a different time for each consumer/configuration.
I don't disagree that someone may want to identify the purpose of the child channel, but that then means we need some way to identify the purpose of the child channel. That's a bigger lift and opens up lots of complexities on how you will categorize the child channels' purposes. In our TL discussion about it, nobody could come up with a strong need for the info, we so left it for future work if/when it is needed.
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!
| * Conflict Resolution: Mandatory internal settings (`O_internal`) generally take | ||
| precedence over user-provided child options (`O_child`) to ensure correctness. |
There was a problem hiding this comment.
Why is the user-provided options given less precedence here? There is more than one example of existing options where the user-provided option overrides values provided by things like the name resolver or the credentials. The reasoning being the user knows what they are doing, and if they are doing something stupid, we throw our hands up in the air.
|
|
||
| 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.
No description provided.