Skip to content

Gateway API conformance — baseline run (2026-06-25)

A baseline diagnostic run of the upstream Kubernetes Gateway API conformance suite (sigs.k8s.io/gateway-api/conformance @ v1.5.1, the version aether pins) against talos-main (aether 0.42.0, rev 68, status-condition reporting live). Goal: an authoritative pass/fail/skip breakdown to prioritise remaining conformance work — not to make everything pass. Aether was not modified or redeployed.

TL;DR

Profile Setup Tests run PASS FAIL SKIP Verdict
GATEWAY-HTTP (north-south) blocked 0 0 0 (all) Suite aborts in Setup — it creates its own Gateways in gateway-conformance-infra; aether's edge controller only reconciles aether-ingress, so those Gateways never go Accepted/Programmed and NamespacesMustBeReady times out.
MESH-HTTP (east-west / GAMMA) passed 7 4 3 123 The suite actually executes against aether's transparent-capture path. Failures map cleanly to known filter gaps.

Headline: GATEWAY-HTTP cannot run at all against aether's edge model as-is (an infra/addressing/namespace-scoping blocker, documented below — this negative result is itself the finding). MESH-HTTP runs and is 4/7 on the tests its profile gates in, with the 3 failures being exactly the unimplemented HTTPRoute filters.

How it was run

A small standalone Go runner (isolated module, not committed to the repo — it is a one-off diagnostic, not a Bazel test target) drove suite.NewConformanceTestSuite programmatically rather than the CLI RunConformance, so profiles and the supported-features set could be set explicitly:

  • GatewayClassName: "aether", conformance CRDs already at v1.5.1 (standard channel) on the cluster.
  • Supported features advertised conservatively (the suite skips tests for features you don't claim):
  • GATEWAY-HTTP: Gateway, HTTPRoute, ReferenceGrant
  • MESH-HTTP: Mesh, HTTPRoute
  • ConformanceProfiles: GATEWAY-HTTP and (separately) MESH-HTTP.
  • ManifestFS: conformance.Manifests — required when calling the suite programmatically: only the CLI DefaultOptions wires the embedded base/mesh manifest FS, so without it Setup silently applies nothing.
  • AllowCRDsMismatch: true — talos-main has TCPRoute/UDPRoute installed from the experimental channel (aether's L4 routes) alongside standard-channel HTTP CRDs; the suite refuses mixed channels otherwise. GATEWAY-HTTP/MESH-HTTP need none of the L4 CRDs, so the mismatch is benign here.

All suite-created namespaces were applied with cleanup and verified removed after each run (gateway-conformance-* — none left behind).

GATEWAY-HTTP — the blocker (authoritative negative result)

The suite's Setup applies base/manifests.yaml, which creates four Gateways of class aether in namespace gateway-conformance-infra (same-namespace, all-namespaces, backend-namespaces, same-namespace-with-https-listener), then calls NamespacesMustBeReady, which waits for every Gateway in those namespaces to report Accepted=True AND Programmed=True before any test runs.

Observed live during Setup:

NAME                                 CLASS    ACCEPTED   PROGRAMMED
all-namespaces                       aether   Unknown    Unknown
backend-namespaces                   aether   Unknown    Unknown
same-namespace                       aether   Unknown    Unknown
same-namespace-with-https-listener   aether   Unknown    Unknown

# same-namespace .status.conditions:
#   Accepted   Unknown  reason=Pending  "Waiting for controller"
#   Programmed Unknown  reason=Pending  "Waiting for controller"

"Waiting for controller" is the default condition the API server stamps — aether's edge controller never touches it, because the edge reconciler only lists/programs Gateways in aether-ingress (one edge Deployment per release, serving class aether from that one namespace on a single LB). Result: NamespacesMustBeReady exhausts its 5-minute budget (context deadline exceeded) and the suite aborts in Setup before enumerating a single test.

Notably, the backend workload pods came up fine (web-backend, app-backend, infra-backend, grpc-* all reached 1/1 Running) — aether's CNI/transparent-capture does not block the conformance backends. The sole GATEWAY-HTTP blocker is Gateway status not being published for Gateways outside aether-ingress.

What it would take to run the FULL GATEWAY-HTTP suite

This is the "what's needed to actually run the suite" deliverable:

  1. Namespace-agnostic edge Gateway reconciliation (the hard blocker). The edge controller must publish Accepted/Programmed for class-aether Gateways wherever they live (at least in the suite's gateway-conformance-infra), not only in aether-ingress. Until then the suite can never get past Setup. Aether's "one edge Deployment, one LB, Gateways-in-aether-ingress" model is the architectural tension here.
  2. Per-Gateway addressing. The suite creates many Gateways and each expects its own .status.addresses. Aether serves all class-aether Gateways from a single edge LB (192.168.100.101). Even with (1), every programmed Gateway would advertise the same address; conformance tests that send to a Gateway's reported address would all hit the one edge. A faithful full run needs either per-Gateway LB addresses or an accepted shared-address/host-multiplexing model the suite tolerates.
  3. ReferenceGrant is a CORE feature of GATEWAY-HTTP. The profile mandates it; aether's data-plane cluster name is namespace-free (<svc>.<meshDomain>), so cross-namespace backendRef enforcement is not in the routing model today (docs/conformance/gateway-api-features.md lists it N/A → Planned). Several GATEWAY-HTTP core tests (GatewaySecretReferenceGrant*, HTTPRouteInvalidCrossNamespaceBackendRef, HTTPRouteInvalidReferenceGrant) will fail until grant enforcement lands.
  4. GatewayClass supportedFeatures advertisement. gatewayclasses/aether .status currently carries only the Accepted condition — no supportedFeatures list. The suite's EnableAllSupportedFeatures/auto-detect path reads that field; without it, features must be passed manually (as this run did). Publishing status.supportedFeatures is the clean way to let the suite self-configure.
  5. CRD channel hygiene. Mixed standard + experimental Gateway API CRDs on the cluster trip the suite unless AllowCRDsMismatch is set. For a published conformance run, settle on a single channel.

MESH-HTTP — actually executed (4 PASS / 3 FAIL / 123 SKIP)

The mesh profile's readiness gate (MeshNamespacesMustBeReady) only waits on pods, not on Gateways (a Service is the parent in GAMMA), so Setup succeeded (echo pods ready in ~26s) and the suite ran the mesh tests against aether's transparent-capture path.

PASS (4):

Test What it proves
MeshBasic Baseline east-west request through aether's capture works.
MeshHTTPRouteSimpleSameNamespace GAMMA HTTPRoute (parentRef=Service) routes.
MeshHTTPRouteMatching Path/header match vocabulary on the capture path.
MeshTrafficSplit Weighted backend split (canary) — basic distribution holds.

FAIL (3) — all map to known unimplemented HTTPRoute filters:

Test Root cause (known gap)
MeshHTTPRouteRequestHeaderModifier Request header-modifier filter not yet translated (being added in a parallel PR). Request reaches the backend unmodified.
MeshHTTPRouteRedirectHostAndStatus Redirect filter not implemented — the request passes through to the backend (Url=http://echo/...) instead of returning a 3xx redirect.
MeshHTTPRouteWeight Stricter weight-distribution assertion didn't converge in-window (vs. the looser MeshTrafficSplit). Likely propagation/timing on the capture path; revisit after filters.

SKIP (123): everything gated by features/profiles not claimed in this run — the entire GATEWAY-* surface (GatewayWithAttachedRoutes, GatewayModifyListeners, GatewayStaticAddresses, frontend/backend client-cert, BackendTLSPolicy*), all edge HTTPRoute* tests, GRPCRoute*, TLSRoute*/TCPRoute/UDPRoute, and ReferenceGrant/CrossNamespace tests. These are skips-by-design (conservative feature set + single profile), not failures.

Top failure categories mapped to aether's known gaps

Category Conformance signal Aether status
HTTPRoute filters (request/response header mod, redirect, rewrite, mirror) MeshHTTPRouteRequestHeaderModifier, MeshHTTPRouteRedirectHostAndStatus FAIL; all edge HTTPRoute*Redirect/*HeaderModifier SKIP Planned (header-mod in a parallel PR; redirect/rewrite/mirror not started). Highest-value next work — it's the bulk of the would-be failures.
ReferenceGrant / cross-namespace Core feature of GATEWAY-HTTP; tests SKIP/would-FAIL N/A → Planned; namespace-free cluster naming. Conformance-only follow-up.
Interception model (mesh) Mesh tests run but only on the suite's echo Service; weight-distribution flake GAMMA capture works for the conformance echo client; tighten weighted distribution. Arbitrary-Service interception vs. aether's generated mesh VIPs is the 018 tension.
Status edge-cases *ObservedGenerationBump, GatewayModifyListeners, GatewayWithAttachedRoutes SKIP Core status now lands (Accepted/Programmed/ResolvedRefs + attachedRoutes); these are reachable once the edge namespace-scoping blocker (above) is removed.
Edge addressing / namespace scoping GATEWAY-HTTP Setup blocker Architectural: one edge Deployment, one LB, Gateways-in-aether-ingress. The single biggest item gating a full north-south run.

Reproduction

The runner (standalone module, ~80 LOC) sets the options above and calls cSuite.Setup(t, tests.ConformanceTests) → cSuite.Run(...) → cSuite.Report(). Key non-obvious requirements when driving the suite programmatically (vs. the CLI): set ManifestFS to conformance.Manifests, set AllowCRDsMismatch on a mixed-channel cluster, and advertise the supported-features set explicitly.

Next steps (priority order)

  1. HTTPRoute filters (header mod → redirect → rewrite → mirror) — converts the 3 mesh FAILs and the largest block of edge SKIPs into PASSes.
  2. Namespace-agnostic edge Gateway status so GATEWAY-HTTP Setup can pass and the north-south suite becomes runnable at all.
  3. Publish GatewayClass.status.supportedFeatures so the suite self-configures.
  4. ReferenceGrant enforcement (or a documented, accepted exemption) for the GATEWAY-HTTP core requirement.
  5. Decide the per-Gateway addressing story for a faithful multi-Gateway run.