[tmpnet] Enable installation of chaos mesh to local kind cluster

[maru-ava]

Why this should be merged

Deploying chaos mesh to a local kube cluster is intended to simplify local experimentation with fault injection testing.

How this works

• Optionally deploys chaos mesh by starting a kind cluster with tmpnetctl start-kind-cluster --install-chaos-mesh

How this was tested

• CI against regression
• CI job (robustness) that validates deployment of kind with chaos mesh
• Manually invoked tmpnetctl start-kind-cluster --install-chaos-mesh and ran a chaos experiment

Need to be documented in RELEASES.md?

N/A

TODO

• Merge [tmpnet] Enable externally accessible URIs for kube-hosted nodes #4016

[github-actions]

This PR has become stale because it has been open for 30 days with no activity. Adding the lifecycle/frozen label will cause this PR to ignore lifecycle events.

[github-actions]

This PR has become stale because it has been open for 30 days with no activity. Adding the lifecycle/frozen label will cause this PR to ignore lifecycle events.

[Copilot]

Pull Request Overview

This PR adds an optional flag to install Chaos Mesh into a local kind cluster, updates existing ingress controller port usage to a shared constant, and integrates Chaos Mesh deployment logic with Helm and readiness checks.

• Introduces --install-chaos-mesh flag and installChaosMesh parameter
• Adds Chaos Mesh constants, deployChaosMesh, isChaosMeshRunning, and waitForChaosMesh functions
• Refactors ingress port settings to use ingressNodePort constant and updates the kind script comment

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
tests/fixture/tmpnet/tmpnetctl/main.go	Adds installChaosMesh flag and passes it through to StartKindCluster
tests/fixture/tmpnet/start_kind_cluster.go	Defines Chaos Mesh constants, handles installChaosMesh branch, and implements Helm deployment and readiness polling
scripts/kind-with-registry.sh	Updates comment to reference the ingressNodePort constant

Comments suppressed due to low confidence (2)

tests/fixture/tmpnet/start_kind_cluster.go:131

• No existing tests cover the installChaosMesh branch; consider adding a unit or integration test to verify that Chaos Mesh is deployed when the flag is set.

	if installChaosMesh {

tests/fixture/tmpnet/start_kind_cluster.go:58

• Accessing the dashboard at chaos-mesh.localhost requires a hosts entry (e.g., /etc/hosts); please document this requirement in the README or RELEASES.md.

	chaosMeshDashboardHost  = "chaos-mesh.localhost"

[maru-ava]

Updated to use a longer timeout - chaos mesh deployment on top of kind and nginx deployment can take more than 2 minutes.

[maru-ava]

Updated to add a CI check of deployment

[RodrigoVillar]

LGTM - also ran load test with chaos mesh which worked 👍

[Elvis339]

I'm curious about the architectural decision to have Kind cluster setup entirely in Go code rather than using a more declarative approach with YAML manifests, Helm charts, and scripts.

My initial thoughts from a development workflow perspective, a declarative approach might offer some advantages like easier configuration where developers could modify YAML files without recompiling Go code or understanding the tmpnet

For example, something like:

# scripts/setup-dev-cluster.sh
./scripts/kind-with-registry.sh
kubectl apply -k {{path}}
helm install ingress-nginx -f values/ingress.yaml
helm install chaos-mesh -f values/chaos-mesh.yaml --create-namespace
kubectl wait --for=condition=available deployment/ingress-nginx-controller

However, I recognize there might be good reasons for the Go approach, just curios to understand what drove to having this programatic rather than declarative.

[maru-ava]

I'm curious about the architectural decision to have Kind cluster setup entirely in Go code rather than using a more declarative approach with YAML manifests, Helm charts, and scripts.

My initial thoughts from a development workflow perspective, a declarative approach might offer some advantages like easier configuration where developers could modify YAML files without recompiling Go code or understanding the tmpnet

For example, something like:

# scripts/setup-dev-cluster.sh
./scripts/kind-with-registry.sh
kubectl apply -k {{path}}
helm install ingress-nginx -f values/ingress.yaml
helm install chaos-mesh -f values/chaos-mesh.yaml --create-namespace
kubectl wait --for=condition=available deployment/ingress-nginx-controller

However, I recognize there might be good reasons for the Go approach, just curios to understand what drove to having this programatic rather than declarative.

What you're suggesting would involve replacing logic in golang with logic in a shell script. Sure, the golden path looks nice, but ensuring everything is logged and error checked ends up being more complicated and less reliable than what is possible with golang.

I'm also not clear why 'recompiling golang code' would be an issue? ./bin/tmpnetctl already does this automatically, and even that invocation can be with tasks rather than directly.

What modifications are you envisioning exactly?

[maru-ava]

I'm curious about the architectural decision to have Kind cluster setup entirely in Go code rather than using a more declarative approach with YAML manifests, Helm charts, and scripts.

• Note also that yaml manifests are used for some deployment tasks (e.g. monitoring and rbac).
• Another motivation for golang was simplifying reuse across repos (subnet-evm, hypersdk) since golang code can be vendored with go modules but scripts cannot. This appears less and less important over time.