v1 e2e (#37) leaves cloud-provider-kind running but only asserts Deployment Available=True. That does not prove LoadBalancer / Ingress / Gateway traffic reaches the workload the way a local deployah cluster up user expects.
Extend the Kind e2e suite (after #37) to:
- Deploy a fixture that exposes via LoadBalancer (and/or Ingress/Gateway if already covered by localkube defaults).
- Resolve the external address through cloud-provider-kind.
- HTTP(S) check that the service responds (bounded timeout).
- Keep the check on the shared cluster; do not add a second Kind create/destroy cycle.
Depends on #37.
Skipping HTTP forever and trusting Deployment Ready only is a weaker signal for the cloud-provider path. Testcontainers / k3s with its own LB story diverges from the product Kind path, so I'd rather not go there.
v1 e2e (#37) leaves cloud-provider-kind running but only asserts Deployment
Available=True. That does not prove LoadBalancer / Ingress / Gateway traffic reaches the workload the way a localdeployah cluster upuser expects.Extend the Kind e2e suite (after #37) to:
Depends on #37.
Skipping HTTP forever and trusting Deployment Ready only is a weaker signal for the cloud-provider path. Testcontainers / k3s with its own LB story diverges from the product Kind path, so I'd rather not go there.