router: add pluggable networking providers#85
Conversation
|
Question: if the AgentGateway doesn't use XDS, you might get broken if some logic gets pushed into the XDS configuration? The XDS is minimal right now, but will highly likely change. That being said, Envoy should be an implementation detail and I think it makes sense to make this pluggable. Also, it would be good to use package boundaries to delineate the providers if possible. |
One note on this - agentgateway does support dynamic configuration via the XDS gRPC APIs it just has different types sent over that service (so cannot use the existing xDS server which sends Envoy-specific Listeners/Clusters/etc). |
|
Sorry for the late reply. I think at this point in the project, it will be hard to maintain two separate implementations of routing logic in tree -- it's highly likely that the configuration will evolve quite a bit in the early stages of this project. I just think it's going to be difficult pre-alpha/beta to consolidate on any real contracts here as of yet. It probably makes the most sense to add an option to disable reconciliation of the envoy and only run the ext_proc plugin. We keep the K8s Service and you can use the Deployment with the same labels in your custom implementation of the router. |
|
Hi John Howard (@howardjohn) -- looks like there are further discussions that have elaborated on this (see #393). Do we want to keep going on this or close this? |
|
yeah I think we can replace with 393 |
This PR extends the router to support pluggable network providers rather than a hardcoded Envoy. Envoy remains the default with no changes.
As we build out the feature set of substrate, we will have an expanded set of requirements on networking. For example, #15 (comment) expresses a need to inject credentials and a desire to be able to plug in the proxy of your choice. IMO this is very important: there are a number of projects coming up in this space specializing in the needs of agentic traffic that make sense to plug in here.