A110: Child Channel Options #529

AgraVator · 2025-12-23T08:38:21Z

No description provided.

markdroth

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 · 2025-12-24T00:50:17Z

A110-child-channel-plugins.md

@@ -0,0 +1,215 @@
+# **A110: Child Channel Configuration Plugins**
+
+* **Author(s)**: [Abhishek Agrawal](mailto:[email protected])


There are a couple of fields missing here, in particular the "approver" and "mailing list link" fields.

Please make sure you are following the gRFC template: https://github.com/grpc/proposal/blob/master/GRFC-TEMPLATE.md

markdroth · 2025-12-24T00:53:11Z

A110-child-channel-plugins.md

+
+## **Abstract**
+
+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.


I don't think we want to specify a different approach in each language. I think what we want here is to describe an approach in a language-agnostic way, which we will then use in all languages.

To be clear, I'm fine with specifying details of how things will work in individual languages if that is helpful to clarify the design. But the main goal of an "A"-series gRFC is to specify a feature that will work essentially the same way in all languages, and we need to approach it from that perspective.

You may want to look at several of the recent "A"-series gRFCs for examples.

markdroth · 2025-12-24T00:55:20Z

A110-child-channel-plugins.md

+Complex gRPC ecosystems often require the creation of auxiliary channels that are not directly instantiated by the user application. Two primary examples are:
+
+1. **xDS (Extensible Discovery Service)**: 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. Currently, users have limited ability to configure this internal control plane channel.
+2. **Advanced Load Balancing (RLS, GrpcLB):** Policies like RLS (Route Lookup Service) and GrpcLB, as well as other high-level libraries built on top of gRPC, frequently create internal channels to communicate with look-aside load balancers or backends.


RLS isn't a public API and shouldn't be mentioned here.

I think better examples to cite here are ext_authz (see WIP gRFC A92 in #481) and ext_proc (see WIP gRFC A93 in #484). Note that those cases are not LB policies, so we should consider whether the plumbing needs to be different to support those cases.

markdroth · 2025-12-24T01:00:40Z

A110-child-channel-plugins.md

@@ -0,0 +1,215 @@
+# **A110: Child Channel Configuration Plugins**


I think this should be called "Child Channel Options". The mechanism we're describing here isn't really a plugin thing.

markdroth · 2025-12-24T01:13:34Z

A110-child-channel-plugins.md

+
+There is currently no standardized way to configure behavior for these child channels.
+
+* **Metrics**: Users need to configure metric sinks so that telemetry from internal channels can be read and exported.


It's not clear to me what this list is trying to communicate, because each of the three items here is something completely different:

Metrics are one of the main features supported by stats plugins, but if that's what you're talking about, then I would expect you to also mention tracing.

I don't think we need to talk about interceptors specifically here, since the mechanism we're describing isn't really specifically about interceptors; it's about setting options for child channels in general.

The "no global state" thing isn't even talking about state that may be propagated to child channels; it's talking about why we can't use global state as a mechanism for how to do this propagation. I think that should just be a separate paragraph.

I think we should instead start this section by talking about the problem that actually motivated this design, which is the need to set StatsPlugins on a per-channel basis and also propagate them to child channels. We can then discuss why it's not sufficient to just use the global registry.

This discussion should reference gRFCs A66 and A72, which describe StatsPlugins.

markdroth · 2025-12-24T01:41:39Z

A110-child-channel-plugins.md

+  // The child_args_struct is wrapped as a pointer argument.
+  // We use a VTable to ensure the nested struct is safely copied or
+  // destroyed during the parent channel's lifetime.
+  grpc_arg parent_arg = grpc_channel_arg_pointer_create(


This is using a C-core API, which is not what we'd want applications to use.

Instead, we would probably just add a method to grpc::ChannelArguments that looks something like this:

void SetChildChannelArgs(grpc::ChannelArguments child_args);

markdroth · 2025-12-24T01:41:47Z

A110-child-channel-plugins.md

+  auto channel = grpc::CreateCustomChannel(
+      "xds:///my-service", 
+      grpc::InsecureChannelCredentials(), 
+      grpc::ChannelArguments::FromC(parent_args)


There is no FromC() method on grpc::ChannelArguments, although that method does exist on some of our internal channel args types. This looks an awful lot like an AI hallucination. ;P

markdroth · 2025-12-24T01:42:42Z

A110-child-channel-plugins.md

+
+### **Why Language-Specific Approaches?**
+
+While the concept is cross-language, the mechanisms for channel creation differs significantly:


These differences are really just implementation details. I think the overall approach is the same across languages, and we should describe it as such.

markdroth · 2025-12-24T01:58:09Z

A110-child-channel-plugins.md

+
+### **Java**
+
+In Java, the configuration will be achieved by accepting functions (callbacks). The API allows users to pass a `Consumer<ManagedChannelBuilder<?>>` (or a similar functional interface). When an internal library (e.g., xDS, RLS, gRPCLB) creates a child channel, it applies this user-provided function to the builder before building the channel.


The API proposed for Java and Go seems to be only for channels, not for servers. However, the xDS, ext_authz, and ext_proc cases will also happen on the gRPC server side. Do we need to solve this problem also on the server side?

(The C-core approach will work on both client and server sides.)

markdroth · 2025-12-24T02:00:23Z

A110-child-channel-plugins.md

+
+Complex gRPC ecosystems often require the creation of auxiliary channels that are not directly instantiated by the user application. Two primary examples are:
+
+1. **xDS (Extensible Discovery Service)**: 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. Currently, users have limited ability to configure this internal control plane channel.


In the xDS case, the same xDS channel will be used in multiple channels for the same target. We need to document what the behavior will be if the application creates multiple channels to the same target with different child channel args. (It will just use whatever child channel args are passed to the first channel to be created.)

AgraVator added 3 commits December 23, 2025 14:07

propose child channel plugins

2bc6a36

correct formatting

bec26c9

use actual gRFC number

29bcc2a

AgraVator requested review from dfawley, easwars, ejona86, markdroth and sergiitk December 23, 2025 08:57

markdroth changed the title ~~A110: Child Channel Plugins~~ A110: Child Channel Options Dec 24, 2025

markdroth reviewed Dec 24, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

A110: Child Channel Options #529

A110: Child Channel Options #529

Uh oh!

AgraVator commented Dec 23, 2025

Uh oh!

markdroth left a comment

Uh oh!

markdroth Dec 24, 2025

Uh oh!

markdroth Dec 24, 2025

Uh oh!

markdroth Dec 24, 2025

Uh oh!

markdroth Dec 24, 2025

Uh oh!

markdroth Dec 24, 2025

Uh oh!

markdroth Dec 24, 2025

Uh oh!

markdroth Dec 24, 2025

Uh oh!

markdroth Dec 24, 2025

Uh oh!

markdroth Dec 24, 2025

Uh oh!

markdroth Dec 24, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		@@ -0,0 +1,215 @@
		# A110: Child Channel Configuration Plugins

		* Author(s): [Abhishek Agrawal](mailto:[email protected])


		## Abstract

		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.


		There is currently no standardized way to configure behavior for these child channels.

		* Metrics: Users need to configure metric sinks so that telemetry from internal channels can be read and exported.


		### Why Language-Specific Approaches?

		While the concept is cross-language, the mechanisms for channel creation differs significantly:


		### Java

		In Java, the configuration will be achieved by accepting functions (callbacks). The API allows users to pass a `Consumer<ManagedChannelBuilder<?>>` (or a similar functional interface). When an internal library (e.g., xDS, RLS, gRPCLB) creates a child channel, it applies this user-provided function to the builder before building the channel.


		Complex gRPC ecosystems often require the creation of auxiliary channels that are not directly instantiated by the user application. Two primary examples are:

		1. xDS (Extensible Discovery Service): 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. Currently, users have limited ability to configure this internal control plane channel.

A110: Child Channel Options #529

Are you sure you want to change the base?

A110: Child Channel Options #529

Uh oh!

Conversation

AgraVator commented Dec 23, 2025

Uh oh!

markdroth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants