test(infra): prod-fidelity edge test env + e2e suite#276
Conversation
|
doin the last two |
|
now deleting interim env & pointing CI at new env |
Brings up a two-cluster environment that mirrors how the edge really runs: the production gateway version, the firewall data plane real traffic passes through, and the actual path configuration travels to the edge. Lets tests exercise the route customer traffic takes instead of a simplified stand-in. Test scaffolding only; no change to how the edge runs for customers. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JbCy8vy66RdNYzGSgqH6P6
The endpoint that lets the parity test confirm the proxy is running exactly the set the build intended is off by default and served only when asked for. The base deployment reads --enable-programmed-set from the ENABLE_PROGRAMMED_SET env var; flip it to "true" in the downstream edge overlay with a strategic-merge patch on env so the test environment keeps that visibility while production exposes nothing. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JbCy8vy66RdNYzGSgqH6P6
Add a test-infra:test-e2e task that runs the control-plane e2e suite against the live #226 two-cluster environment, mapping the suite's chainsaw aliases (nso-standard/nso-infra) onto this env's upstream and downstream kubeconfigs at invocation. Bring the hardened suite from main onto this branch and pin the operator image to the env's build. Key changes: - add test-infra:test-e2e task; CLI_ARGS selects a single scenario - pin manager and e2e-downstream image tags to d2e62bf - assert the ClusterIssuer CA Certificate is Ready before gateway steps - carry the listener-hostname-collision, tpp-enforce, and tpp-paranoia-validation scenarios from main
The prod-fidelity env installs the downstream GatewayClass as datum-downstream-gateway-e2e; the enforce test hardcoded the bare datum-downstream-gateway, so waf-gw never bound a class and timed out before Programmed. Point the Gateway, diagnostics, and comment at the env's class. waf-gw now programs and benign traffic returns 200.
The gateway-accepted and gateway-invalid-certificate scenarios self- provisioned a per-test EnvoyProxy + GatewayClass in envoy-gateway-system, the single-stack bridge topology the prod-fidelity env retires. That namespace and controller don't exist on the shared env, so both timed out. Point them at the env's shared GatewayClass and assert the cert-health behavior (#212) at the gateway-status level, where the upstream controller expresses it: bad listener withheld from the edge, good programmed, plain-language reason surfaced, recovery propagated. Drop the bespoke proxy and the backend-re-encrypt wire checks; shared-plane serving is already covered by the WAF enforce test. Key changes: - remove self-provisioned EnvoyProxy/GatewayClass; use the env class - keep the full #212 status arc, incl. recovery - drop the envoy-gateway-system connectivity probes
chainsaw writes no report by default, so a hung or killed run left no trail on disk. Emit a JSON report (path/name overridable) so a stall is diagnosable after the fact instead of only in lost terminal scrollback.
The suite commits carried a fixed image tag from the standalone branch; the env sets the operator tag at deploy time (nso-image / extension-server), so restore the placeholder tags to avoid committing a stale build reference.
Two main-carried WAF scenarios failed on the two-cluster env: - enforce-blocks-attack and neutralize-inverted hardcoded the bare datum-downstream-gateway class; the env installs datum-downstream-gateway-e2e, so waf-gw never programmed. - neutralize-inverted stripped the paranoia CEL off the CRD to inject a grandfathered inverted policy, but it runs against the downstream cluster whose replicated CRD carries no such validation, so the remove patch failed on a missing path. Guard the strip/restore on the CEL actually being present; when absent the inverted policy applies directly.
The E2E Tests workflow stood up a single-stack bridge (nso-standard /
nso-infra via make kind-*-cluster + prepare-*), which diverged from how
the edge runs in production and from the two-cluster prod-fidelity env.
Point CI at that env instead: install task + helm + the pinned tools,
then `task test-infra:up` and `task test-infra:test-e2e`.
Retire the now-unused bridge: the dev Taskfile, its Makefile targets
(test-e2e, prepare-e2e, prepare-infra-cluster, downstream-crds,
downstream-waf-dataplane, load-image-*, kind-*-cluster, deploy-e2e,
envoy-gateway, external-dns), the bridge kind cluster configs, and the
orphaned config/e2e-downstream manifests.
Key changes:
- rewrite test-e2e.yml to bring up and run the test-infra env
- bump pinned kind to v0.32.0 to match the env's node image
- delete Taskfile.dev.yaml and drop its include
- remove bridge Makefile targets and config/tools/kind/{standard,infra}
- delete config/e2e-downstream/{pki,waf-gateway,extension-server-config}
Update CLAUDE.md and the extension-server enhancement to describe the two-cluster test-infra env (nso-upstream / nso-downstream) and its task-based entrypoints, replacing the retired bridge references (make test-e2e, task dev:*, make prepare-infra-cluster).
Empty commit to re-fire the pull_request synchronize event after the workflow-file change gated the prior run.
Capture the conventions that the CI-on-env switch makes load-bearing: bind to the env's shared data plane (datum-downstream-gateway-e2e, not the bare bridge class or a self-provisioned envoy-gateway-system proxy), provision any scenario dependency in test-infra:up so it exists on the env, and push workflow edits over SSH (the gh HTTPS token lacks the workflow scope).
CI now runs test/e2e (incl. test/e2e/billing) on the prod-fidelity env, but #239 wired the Vector collector into the retired bridge's prepare-infra-cluster. Install it from the env instead, and point its kubernetes_logs source at the env's Envoy namespace (datum-downstream-gateway, not the bridge's envoy-gateway-system). Also add workflow_dispatch to the e2e workflow so the run can be triggered directly instead of only via the gated pull_request event.
cee7e6a to
159ccb7
Compare
The gateway-helm chart is gitignored (config/**/charts), so on a fresh checkout (CI) the eg-crds task's static CRD path does not exist and test-infra:up fails. Build the kustomization with --enable-helm first so the chart is pulled, then apply the CRDs.
The billing scenario self-provisioned its own EnvoyProxy (carrying the JSON access-log File sink the Vector pipeline tails) + GatewayClass in envoy-gateway-system — the retired bridge model. Move the access-log sink onto the env's shared downstream EnvoyProxy (matching production, which emits it) and rework the test to bind to the env's shared class, dropping the self-provisioned proxy/class and the CA copy. Retarget the wire and log-scrape steps from envoy-gateway-system to the env's Envoy namespace, datum-downstream-gateway.
kustomize v5.5.0 probes helm via `helm version -c`; the -c shorthand was removed in helm 3.13, so the latest helm from setup-helm broke every --enable-helm build in test-infra:up. Pin helm to the last release that still accepts it.
load-fixtures builds a connector-tunnel fixture from test/e2e-edge, which is not present on this branch and whose scenario is not in the test/e2e suite CI runs. The step just fails the bring-up on a missing path. Remove it from up; re-add if the e2e-edge suite lands here.
On a freshly brought-up env the suite raced fixed timeouts: the NSO webhook cert is injected after the manager is Available, so early Domain creates hit "context deadline exceeded"; and the first gateway waits on the merged Envoy proxy to spin up, overrunning a 30s assert. Block wait-ready until the webhook actually admits a server-side dry-run and the downstream GatewayClass is Accepted, and give the billing test's first-gateway Programmed assert the same 3m budget the other gateway tests use. Fixes #279.
The manager Deployment intermittently misses the 240s Available wait on a loaded CI runner (heavy two-cluster env). Bump the budget to 360s, and dump the upstream manager + cert-manager state on failure so a genuine stuck manager (vs slow start) is diagnosable. Refs #279.
Parallel execution on one CI runner maximized cold-start races and resource pressure: the billing test's Envoy access-log scrape ran before the merged proxy had served its route. Run chainsaw with --parallel 1 (as the retired bridge harness did) so the shared data plane warms progressively and each scenario runs against a ready proxy. Refs #279.
CI on the env: 9/9 green from cold ✅
Getting there (cold-start hardening, Fixes #279)
Billing metering verified end-to-end on the shared data plane: access log → Note on the PR checkThe required |
There was a problem hiding this comment.
@ecv something I started on the compute project that we should replicate here is switching over to this new federation architecture test environment datum-cloud/test-infra#32
Supersedes #226 in the #247 five-PR stack (the #226 env slot). Combines the rebased prod-fidelity environment with the e2e suite lifted onto it (#275), as a single working PR. Not closing #226 here — @scotwells's to close.
What
main— @scotwells's prod-fidelity two-cluster environment (was ~70 commits behind), replayed on currentmainso it carries Gateway: hostname-less tenant listeners rejected with misleading 'must be unique' (default-listener injection collision) #219 (clear hostname message) and TrafficProtectionPolicy CRD rejected: paranoiaLevels default {} violates detection>=blocking CEL rule #257/fix: reject inverted TrafficProtectionPolicy paranoia levels at admission #251/fix: flag inverted TrafficProtectionPolicy paranoia levels via status condition #252 (TPP paranoia default + CEL validation).test-infra:test-e2etask mapping the chainsaw aliases onto the env's kubeconfigs, with a persisted JSON report; the fulltest/e2esuite adapted to the shared prod-fidelity data plane.Suite: 8/8 green on the live env
gateway-accepted · gateway-invalid-certificate · gateway-listener-hostname-collision · ready-when-context-is-ready · trafficprotectionpolicy-enforce-serves-traffic · trafficprotectionpolicy-enforce-blocks-attack · trafficprotectionpolicy-neutralize-inverted · trafficprotectionpolicy-paranoia-validation
Env-specific adjustments (and why)
datum-downstream-gateway-e2e; tests that hardcoded the baredatum-downstream-gateway(enforce, enforce-blocks-attack, neutralize-inverted) never bound a class and timed out. Aligned.envoy-gateway-system(the single-stack bridge topology this env retires). Reworked to ride the env's shared class and assert the cert-health behavior (Expired/abandoned customer certs can freeze an entire edge — health-gate cert propagation + isolate per-cert failures #212) at the gateway-status level; dropped the bespoke-proxy backend-re-encrypt wire checks (shared-plane serving is covered by the WAF enforce test).Related