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!
| // 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
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!
7 participants
No description provided.