Skip to content

test(infra): prod-fidelity edge test env + e2e suite#276

Merged
ecv merged 20 commits into
mainfrom
test/prod-fidelity-env-rebased
Jul 14, 2026
Merged

test(infra): prod-fidelity edge test env + e2e suite#276
ecv merged 20 commits into
mainfrom
test/prod-fidelity-env-rebased

Conversation

@ecv

@ecv ecv commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

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

  1. Env, rebased onto main@scotwells's prod-fidelity two-cluster environment (was ~70 commits behind), replayed on current main so 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).
  2. e2e suite on the env (Lift the e2e suite onto the prod-fidelity two-cluster env (#226) #275) — a test-infra:test-e2e task mapping the chainsaw aliases onto the env's kubeconfigs, with a persisted JSON report; the full test/e2e suite 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)

  • GatewayClass name — the env installs datum-downstream-gateway-e2e; tests that hardcoded the bare datum-downstream-gateway (enforce, enforce-blocks-attack, neutralize-inverted) never bound a class and timed out. Aligned.
  • Shared data plane — gateway-accepted and gateway-invalid-certificate self-provisioned a per-test EnvoyProxy + GatewayClass in 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).
  • Downstream CRD has no paranoia CEL — neutralize-inverted stripped the CEL to inject a grandfathered inverted policy, but it runs against the downstream cluster whose replicated CRD carries no such validation. Guarded the strip/restore on the CEL being present.

Related

@ecv

ecv commented Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

doin the last two

@ecv ecv changed the title test(infra): prod-fidelity edge test environment (rebased) test(infra): prod-fidelity edge test env + e2e suite (supersedes #226) Jul 14, 2026
@ecv

ecv commented Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

now deleting interim env & pointing CI at new env

scotwells and others added 13 commits July 14, 2026 13:25
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.
@ecv
ecv force-pushed the test/prod-fidelity-env-rebased branch from cee7e6a to 159ccb7 Compare July 14, 2026 17:30
@ecv ecv changed the title test(infra): prod-fidelity edge test env + e2e suite (supersedes #226) test(infra): prod-fidelity edge test env + e2e suite Jul 14, 2026
ecv added 3 commits July 14, 2026 13:45
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.
ecv added 3 commits July 14, 2026 14:59
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.
@ecv

ecv commented Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

CI on the env: 9/9 green from cold ✅

E2E Tests now runs the prod-fidelity env and passes the full suite on a fresh dispatch — run 29362000531:

gateway-accepted · gateway-invalid-certificate · gateway-listener-hostname-collision
ready-when-context-is-ready · trafficprotectionpolicy-{enforce-serves-traffic,
enforce-blocks-attack, neutralize-inverted, paranoia-validation} · billing-http-metering
→ Passed 9 / Failed 0

Getting there (cold-start hardening, Fixes #279)

  • wait-ready now blocks until the NSO webhook admits a server-side dry-run (killed the Domain: context deadline exceeded flake) and the downstream GatewayClass is Accepted.
  • Manager Available budget 240s→360s for loaded runners.
  • Billing's first-gateway Programmed assert given the 3m budget the other gateway tests use.
  • Suite runs --parallel 1 (as the retired bridge did) so the shared merged proxy warms progressively — fixed billing's access-log scrape racing a cold proxy.

Billing metering verified end-to-end on the shared data plane: access log → project_name (ext-server injected) → 4 CloudEvents to the mock gateway.

Note on the PR check

The required E2E Tests status is the pull_request-triggered run, which GitHub holds pending approval because this PR edits the workflow file. The green evidence above is a workflow_dispatch run of the same workflow on this branch; the pull_request run will execute + pass once a maintainer approves it.

@scotwells scotwells left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants