gateway-api
gateway-api copied to clipboard
conformance: support testing mesh implementations
Currently, the conformance tests use a pretty simple echoserver deployment and make HTTP calls from the go test runner to the Gateway IP (which must be reachable from the test runner).
For testing mesh implementations (and in general, but especially mesh), this may not be sufficient. Since we are testing calls to in-cluster Services, we typically cannot reach these from the test runner (out of the cluster). Even mechanism like port-forward typically do not work as they traverse a different network path than real in-cluster calls.
The conformance tests should be enhanced to support these.
I haven't looked at any other meshs, but I am quite familiar with how Istio solves this. We have a standard echo client/server that we use for almost all testing. This has support for all the protocols we support and configuring a wide range of requests parameters (more than curl in some cases - we have logic to send 'illegal' requests as well for testing, overriding ALPN, etc).
The key for testing mesh though is each has a gRPC 'control' endpoint. Each pod we deploy is port-forwarded to from the go test, and when we want to make that pod send a request we send it a ForwardRequest message. This triggers it to make a request (with whatever attributes we want), and then send the response back to the test.
cc @robscott
OSM does something similar; the Go test runner does an exec on the pod to perform the necessary HTTP request. This is definitely something we need to prepare for when it comes to mesh conformance
/assign
In the GAMMA meeting we had some consensus to use the echo server/client Istio is using and move/package it in an Istio agnostic way for use by the gateway-api.
/assign @keithmattix
We've been discussing this a bit over the past few GAMMA meetings, and Keith is starting work on a framework to allow testing GAMMA functionality for mesh implementations.
This issue should be removed from the Implementable milestone in favor of #1686
@keithmattix what's the additional context to the change? Is that this should be closed in favor of that one or just that this one will be for later?
Not closed; this issue just represents actually adding mesh capabilities to the conformance test framework and the other one is the testing plan. Only the testing plan is required for 0.7.0
Sounds good thanks!