What problem would this solve?
v1 e2e (#37) leaves cloud-provider-kind running but only asserts Deployment Available=True. It does not prove LoadBalancer / Ingress / Gateway traffic reaches the workload the way a local deployah cluster up user expects.
What do you want?
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
Alternatives considered
- Skip HTTP forever and trust Deployment Ready only — weaker signal for the cloud-provider path.
- Testcontainers / k3s with its own LB story — diverges from the product Kind path.
What problem would this solve?
v1 e2e (#37) leaves cloud-provider-kind running but only asserts Deployment
Available=True. It does not prove LoadBalancer / Ingress / Gateway traffic reaches the workload the way a localdeployah cluster upuser expects.What do you want?
Extend the Kind e2e suite (after #37) to:
Depends on: #37
Alternatives considered