[vishu42]

Closes #513.

Stacks on #512 → #509 → #508 → #507 → #506. Base is #512's branch; GitHub retargets it as the stack merges.
Depends on #515 (the plan waits 10 minutes for an executor, off main). Without it, a plan that finds the one session busy still fails after a minute, which is what the README now says it doesn't do.

Behaviour change

• Executor: requests = limits = 2 CPU / 2Gi, and the enable-forwarding init container gets fixed equal resources, so the pod is Guaranteed. A chart ConfigMap sets EXECUTOR_MAX_SESSIONS=1 and EXECUTOR_SANDBOX_MEMORY=1536, listed before the user's Secret in envFrom, so a key in the Secret still overrides it. A checksum/config annotation rolls the executor when those defaults change.
• api: new api.resources key, default requests = limits = 2 CPU / 2Gi (Guaranteed).
• README: Secret and values tables show the new defaults; the 41Gi example and the BestEffort paragraphs are gone; "Sizing the executor" says concurrency comes from executor.replicas, how to give a heavy module more memory (memory ≥ sessions × sandbox memory + 512Mi, requests and limits together), and that a run beyond the free executors waits up to 10 minutes, plan or apply, then fails. The Docker Desktop section says the harness runs the defaults.

Configuration impact

A default install now reserves 4 CPU / 4 GiB for api + executor and runs one run at a time. Anyone who set only executor.resources.limits.memory keeps the 2Gi request and gets a Burstable pod; set requests and limits together. api.resources becomes part of the chart's values contract once published. No migration.

Validation

• helm lint --strict deploy/helm/openplan -f deploy/helm/openplan/ci/values.yaml (Helm v4.1.1, CI's pin): 1 chart linted, 0 failed.
• Live check on Docker Desktop (both pods Guaranteed, a real AWS plan completes, a second plan waits past 60 s then completes) follows as a comment here once feat: a plan waits 10 minutes for an executor, like an apply (#513) #515's api image is built.

🤖 Generated with Claude Code

[vishu42]

Verified on Docker Desktop (#513): all three checks pass

Heads: #515 be6ab89f, #516 71b21bcd, #510 be8c4208. Docker Desktop k8s 1.32.2, one node (12 CPU, 7.55 GiB allocatable), Helm v4.1.1.

Setup:

• deploy/helm/evaluation/teardown.sh first, so no kept Secret could carry the old EXECUTOR_MAX_SESSIONS=2. Then setup.sh from feat: add a Docker Desktop evaluation harness for the Helm chart (#317) #510.
• openplan-executor-env held only the artifact store, Temporal and Valkey keys: no session keys.
• api image built from feat: a plan waits 10 minutes for an executor, like an apply (#513) #515 (docker build -f Dockerfile.api -t ghcr.io/openplanhq/openplan-api:gh513 .). Executor and web are :main, retagged :gh513.
• helm install openplan <#516>/deploy/helm/openplan -n openplan -f <#510>/deploy/helm/evaluation/values.yaml --set image.tag=gh513 --wait

1. Both pods Guaranteed, one 1536 MiB session: pass

• status.qosClass is Guaranteed for api and for executor, and both are Running.
• Both containers have requests = limits = cpu: 2, memory: 2Gi. Inside the executor, memory.max is 2147483648 and cpu.max is 200000 100000.
• The enable-forwarding init container has requests = limits = 50m/32Mi. It ended Completed, exit 0.
• envFrom has the openplan-executor ConfigMap first, then openplan-executor-env. The pod carries the checksum/config annotation.
• env in the executor shows EXECUTOR_MAX_SESSIONS=1 and EXECUTOR_SANDBOX_MEMORY=1536.

2. A real 11-resource hashicorp/aws 6.x plan completes: pass

• Fixture: openplanhq/demo-templates, branch fixture/aws-plan-513, modules/aws-plan-513. The provider has the skip flags, and the stack's Environment holds fake AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY.
• The run completed with plan summary add 11, change 0, destroy 0, about 30 s from queued to done.
• Memory, sampled every 3 s:
  • /sys/fs/cgroup/sandboxes/memory.peak = 1,479,774,208 B (1411 MiB) against the 1536 MiB sandbox limit. That figure includes page cache.
  • Executor container memory.peak = 1,544,810,496 B (1473 MiB) against 2048 MiB.
  • memory.events: oom 0, oom_kill 0.
• Executor restarts: 0. lastState is empty, so no OOMKilled.
• Headroom in the sandbox is about 125 MiB on this module. That fits the brief's accepted risk: a heavier AWS state needs the README's path, which raises EXECUTOR_SANDBOX_MEMORY together with the pod's resources.

3. A second plan waits for the executor, then completes: pass

• First, an apply of long-running-apply with duration_seconds = 150 and auto-approve. Once it reached applying (21:08:19 IST), a plan started on a second stack template.
• From 21:08:22 to 21:10:47 the plan showed running/waiting_for_executor: about 145 s. Before feat: a plan waits 10 minutes for an executor, like an apply (#513) #515 it would have failed at 60 s.
• The apply completed at 21:10:50 (add 4). The plan then went fetching_source, then initializing, and completed at 21:10:56 (add 4, no error).
• api and executor restarts: 0.

Everything is torn down: namespace, ingress-nginx, CoreDNS rewrite, the :gh513 images, and the kubelet's exited containers.

— Rahul (engineering)

[vishu42]

The README's ingress example no longer names a controller (5ce0244, a new commit on top):

• The install example's values file now reads className: <your-ingress-class> # kubectl get ingressclass; omit for the cluster default instead of nginx.
• The prerequisites say the chart creates a standard Ingress with no controller-specific annotations, so any controller that serves one works. They also say not to start on ingress-nginx: Kubernetes retired it in March 2026, and it gets no more releases or security fixes.
• The evaluation harness line names Traefik. feat: add a Docker Desktop evaluation harness for the Helm chart (#317) #510 now installs Traefik in place of ingress-nginx.

Verified with the harness end to end on Docker Desktop. The checkout was a local merge of this branch, #510 (now on Traefik) and #515, and was not pushed. Teardown, setup, helm install ... --set image.tag=main, HTTPS sign-in at https://openplan.localhost, and one random-id plan (completed, +3/0/0) all passed, followed by a clean teardown. Details are on #510.

— Rahul (engineering)