fix(control-plane): set gateway resources via Helm values, configurable with GATEWAY_RESOURCES

[rh-amarin]

Supersedes #282.

#282 raised the gateway memory in components/control-plane/manifests/gateway/deployment.yaml. That manifest was removed in #194 when gateways moved to the upstream OpenShell Helm chart. Since then the control plane has not set the gateway container's resources, and the chart default is resources: {} (deploy/helm/openshell/values.yaml at v0.0.116-rhaiv.6). Gateways now run BestEffort: no memory limit, nothing reserved at scheduling, and they are among the first pods evicted under node memory pressure.

This PR:

• always sets the chart's resources value in internal/helm/values.go. The defaults are requests cpu: 100m, memory: 512Mi and limits cpu: 500m, memory: 1Gi, the memory sizing proposed in fix(control-plane): increase gateway memory capacity #282 after the OOMKill at 512Mi.
• adds GATEWAY_RESOURCES, an optional controller env var holding a JSON Kubernetes ResourceRequirements object. It lets each cluster size its gateways from its gitops overlay without rebuilding the image:

  {"requests":{"cpu":"100m","memory":"512Mi"},"limits":{"cpu":"500m","memory":"1Gi"}}

  The value replaces the defaults entirely; it is not merged with them. It must set limits.memory, no request may exceed its limit, and claims is rejected. An invalid value fails controller startup instead of falling back to the defaults, so a typo cannot leave gateways under-sized with no signal. This deliberately differs from GATEWAY_RECONCILE_WORKERS and the other tunables.
• wires the setting through as config.Load → NewGatewayReconciler → ReconcileOpts.GatewayResources → ValuesBuilder.Resources.
• sets GATEWAY_RESOURCES in the Kind overlay (deploy/kind) to lower requests (cpu: 50m, memory: 128Mi) with the default limits, so more gateways fit on the single Kind node. OpenShift and IBM overlays keep the defaults.
• updates openshell-gateway.spec.md (Deployment resources, env var table, Helm provenance table) and openshell-gateway-helm-adoption.spec.md (Core Values table).

The chart renders .Values.resources directly into the gateway container (_gateway-workload.tpl). The reconciler runs helm upgrade on already-deployed releases, so after the control-plane image rolls out, or after GATEWAY_RESOURCES changes, existing gateways pick up the new resources on their next reconcile. That upgrade restarts the gateway pods.

Validation:

• make check
• go build ./..., and go vet / go test for internal/helm, internal/config, internal/gateway, internal/reconciler in components/control-plane
• new tests: TestBuild_GatewayResources (default and override), TestParseGatewayResources (accept and reject cases), TestLoadGatewayResources (unset, valid, invalid fails startup)

As #282 noted, the 1Gi limit adds headroom; it does not establish the cause of memory growth. Peak gateway memory should still be measured during review cycles.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Advanced

Run ID: 4e3fe072-a92d-4870-a5ae-3423c43047ec

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[hypershell-delivery]

Amber review

Status: Complete

View the submitted review.

[hypershell-delivery]

Verdict

This PR gives the gateway container an explicit resources block (fixing the BestEffort/no-memory-limit regression from the Helm-chart adoption) and makes it operator-tunable via GATEWAY_RESOURCES; the new head also adds a Kind overlay that lowers requests so more gateways fit on the single dev node. The implementation, validation, tests, and spec updates are clean; my only open item is the previously raised supervisor-sidecar scope question plus a cross-PR decision on a duplicate memory-sizing PR.

What works well

• ParseGatewayResources is strict in the right ways: DisallowUnknownFields, trailing-data rejection, claims rejection, mandatory limits.memory, non-negative requests, request-not-exceeding-limit, and positive limits. Each branch is covered by a table test (internal/helm/values_test.go TestParseGatewayResources).
• Fail-fast on an invalid GATEWAY_RESOURCES (abort startup rather than silently reverting to defaults) is the correct call for a sizing control and is justified in the code comment (internal/config/config.go L147-156). Errors are wrapped with fmt.Errorf("...: %w", err) throughout.
• resources is set unconditionally in buildCoreValues (internal/helm/values.go L133-139), so even the unset path stops the gateway from running BestEffort. TestBuild_GatewayResources locks in the default and override behavior; TestLoadGatewayResources covers unset/valid/invalid. No panic(), no secret exposure, config kept separate from code, and the spec/provenance/env-var tables are updated consistently.
• The new Kind overlay change (deploy/kind/kustomization.yaml L48-53) sets GATEWAY_RESOURCES to 50m/128Mi requests with the default 500m/1Gi limits. This is a valid override (requests <= limits), the inline comment explains the rationale, and the env-var spec row documents the overlay behavior.

Cross-PR coordination

A separate open PR pursues the same goal - raising the gateway memory request/limit to 512Mi/1Gi - but does so by editing components/control-plane/manifests/gateway/deployment.yaml, a file that no longer exists on main (gateways now deploy via the Helm chart), and it edits the same "Resource requests/limits" bullets in specs/platform/openshell-gateway.spec.md that this PR restructures. That is PR #282. It is a duplicate solution built on the pre-Helm architecture and currently conflicts on the shared spec section, so a maintainer needs to decide to close #282 (or otherwise sequence it) in favor of this PR to avoid two competing memory-sizing changes and conflicting spec edits.

Previous concerns

• Supervisor sidecar may remain BestEffort - still present. buildCoreValues sets only supervisor.image.{repository,tag} (internal/helm/values.go L123-127) and never a supervisor.resources value; the new resources key applies to the gateway container. If the supervisor shares the gateway pod, that container stays without a memory limit even after this fix. This remains a Minor scope question; see the existing inline discussion rather than a new comment. (Confidence: Medium - verified the values builder sets no supervisor resources; did not confirm the chart's supervisor default.)
• The prior cross-PR coordination item on the duplicate memory-sizing PR is still present and is carried forward in the Cross-PR coordination section above.

---

Findings Summary (ordered by severity, highest first):

1. [Minor] Supervisor sidecar container may remain BestEffort; only the gateway container gets a resources block - Container Resources (internal/helm/values.go L123-139) - already tracked in an existing inline thread

Convention Checklist:

Convention	Result
No panic() in production code	Pass
Errors wrapped with fmt.Errorf context	Pass
No secrets in logs or responses	Pass
Input validated (GATEWAY_RESOURCES JSON)	Pass
Config separate from code	Pass
Test diff scrutiny (only additive tests)	Pass
Spec/docs updated consistently	Pass
Conventional commit message	Pass