Conformance test results for agentgateway are confusing

[rouke-broersma]

What would you like to be added:

The conformance test results list agentgateway as it's own gateway api controller. As far as I can tell agentgateway is not a gateway api controller but rather a dataplane proxy. KGateway is a gateway api controller that supports both agentgateway and envoy as the dataplane proxy but is listed as kgateway for the envoy conformance and as agentgateway for the agentgateway conformance. I could understand the organization name being agentgateway if for example agentgateway support in KGateway is primarily managed by agentgateway, however at least the project name should imo be KGateway (Envoy) and KGateway (AgentGateway).

This was discussed here but does not seem to have been properly resolved (imo)
#4209 (comment)

The way the project would prefer to position it as is that it is Agentgateway with mode Kgateway rather than the inverse. This is also how it's described on the implementation list (Agentgateway with Kgateway).

I can understand why AgentGateway might want to position it this way, however AgentGateway simply is not a gateway api controller. This positioning is confusing to users.

The KGateway docs are pretty imo pretty clear so I don't know where this position comes from:

What is kgateway?
Kgateway is a control plane that implements the Kubernetes Gateway API for both microservices and AI workloads. The control plane translates your Kubernetes Gateway API resources into the configuration that the underlying data plane proxy can understand. The proxy layer is handled by kgateway’s implementation of Envoy for microservices or agentgateway for AI workloads.

Why this is needed:

In my opinion conformance tests should reference the controller implementation as the implementation name, not the dataplane proxy being used. This so users can make a fair comparison between different implementations. This is especially import now that ingress-nginx deprecation has been properly announced and many users will be exploring their migration options.

[howardjohn]

Hey @rouke-broersma , thanks for the issue. Sorry for the confusion here. I believe this is a transient state that will become more clear as some recent work concludes to make Agentgateway more independent from Kgateway. Both projects maintainers wish to have Agentgateway as an independent thing from Kgateway. Much like how other proxies have a coupled first-class controller (for example, to pick on one, "Traefik Proxy" is a data plane, but makes no distinction from the data plane vs control plane, as they are all under one 'Traefik' umbrella), agentgateway does as well. For example, agentgateway has already recently shifted to its own independant CRDs (under agentgateway.dev), and in the coming weeks its own deployment (e.g helm install oci://charts.agentgateway.dev), etc.

[rouke-broersma]

I see, so the agentgateway conformance test results are not KGateway results with the agentgateway integration enabled but rather a new control plane that hasn't been released yet?

Much like how other proxies have a coupled first-class controller (for example, to pick on one, "Traefik Proxy" is a data plane, but makes no distinction from the data plane vs control plane, as they are all under one 'Traefik' umbrella)

Sure, if AgentGateway has it's own control plane there is no need to make a distinction. My conclusion based on public documentation for both projects + the version numbers used was that the conformance test results are KGateway control plane driving AgentGateway as the data plane. If AgentGateway is developing it's own control plane called AgentGateway it of course makes sense to have conformance test results where the implementation is only called AgentGateway without distinction, just as Traefik lists their conformance test results.