docs: add Apache APISIX Ingress Controller 2.2.0 conformance reports - #5182
docs: add Apache APISIX Ingress Controller 2.2.0 conformance reports#5182AlinsRan wants to merge 1 commit into
Conversation
Two reports for 2.2.0, one per deployment mode: the controller drives one shared APISIX data plane, configured either through the Admin API against etcd (default) or pushed in full to an etcd-less APISIX (apisix-standalone). GATEWAY-GRPC passes core and extended with nothing skipped. GATEWAY-HTTP and GATEWAY-TLS are partial, and the skips are listed with their reasons in the README.
kubernetes-prow
Bot
added
release-note-none
|
|
|
Welcome @AlinsRan! |
kubernetes-prow
Bot
added
size/L
|
Hi @AlinsRan. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
kubernetes-prow
Bot
added
the
cncf-cla: no
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: AlinsRan The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
kubernetes-prow
Bot
added
cncf-cla: yes
| - TLSRouteHostnameIntersection | ||
| - TLSRouteInvalidBackendRefNonexistent | ||
| - TLSRouteInvalidBackendRefUnknownKind | ||
| - TLSRouteSimpleSameNamespace |
There was a problem hiding this comment.
if this implementation is not passing the most basic TLSRoute test, what is it passing? I think it would be better to not claim GATEWAY-TLS support in this case
|
I understand where you are coming from with the TLSRoute skips, but at the moment, doing TLS passthrough with TLSRoute is considered Core conformance for that object; if you don't support TLS passthrough with TLSRoute, it's not correct to say you support TLSRoute. To be honest, we never even considered that an implementation would not support passthrough, because in most cases it's easier to implement than TLS termination. I'm very curious as to why APISIX chooses not to implement TLS passthrough. Perhaps you could explain that a bit? However, I don't think we can accept the conformance report as it currently stands, because, as I said, Passthrough support is considered Core for TLSRoute. |
kubernetes-prow
Bot
added
the
needs-rebase
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
3 participants
What type of PR is this?
/kind documentation
What this PR does / why we need it
Adds conformance reports for Apache APISIX Ingress Controller 2.2.0, the first release of this project to implement Gateway API v1.6.0, and lists it under Conformant implementations.
Two reports, one per deployment mode. The controller drives one shared APISIX data plane rather than provisioning one per Gateway, and configures it either through the APISIX Admin API against etcd (
default) or by pushing the whole configuration to an etcd-less APISIX (apisix-standalone, what APISIX calls its API-driven mode). Both modes run the same suite.Nothing fails in either report.
The skips are listed with their reasons in the README and in
test/conformance/conformance_test.goupstream. Four TLSRoute tests pinmode: Passthrough, which APISIX does not do because it terminates TLS and matches stream routes by SNI.HTTPRouteMultipleGatewayswants a route served independently from each parent, which one shared data plane does not do. The rest are gaps tracked for follow-up.The reports come from the
APISIX Conformance Testworkflow run on the 2.2.0 tag, which pulls the published 2.2.0 images, and are submitted exactly as produced. The README's Reproduce section runs the same steps by hand.Which issue(s) this PR fixes
None.
Does this PR introduce a user-facing change?