pal-e-docs

Review: ArgoCD repo-server memory bump (1 alert)

review-item-191-2026-03-18 Review

review needs-refinement
Project

Verdict: NEEDS_REFINEMENT

Template Completeness

  • [x] Lineage
  • [x] Repo
  • [x] User Story
  • [x] Context
  • [x] File Targets
  • [x] Acceptance Criteria
  • [x] Test Expectations
  • [x] Constraints
  • [x] Checklist
  • [x] Related

File Targets

  • [x] ~/pal-e-services/terraform/main.tf lines 93-97 — verified: repoServer block exists at exactly those lines with requests.memory = "64Mi" and limits.memory = "256Mi" matching the ticket description

Repo Placement

MISMATCH. The Forgejo issue is filed on forgejo_admin/pal-e-platform, but the ### Repo section correctly states forgejo_admin/pal-e-services and the file target is in ~/pal-e-services/terraform/main.tf. The PR must be opened on pal-e-services, not pal-e-platform. The issue should either be moved to pal-e-services or a cross-repo reference should be added so the agent opens the PR on the correct repo.

Dependencies

  • Board item #188 (Issue #109: "Platform cleanup — resolve 15 alerts + stabilize CI") is in_progress and is the umbrella issue. #112 is a child ticket. No blocking dependency — can be worked independently.
  • Board item #192 (Issue #113: "Apply Terraform state drift") is in todo. If state drift is applied first, it could cause plan noise, but these are independent changes in different Helm values blocks. No true dependency.
  • Board item #162 (todo-argocd-image-updater-oom) is in done — a prior ArgoCD OOM fix for image-updater (separate Helm release). No conflict.

Acceptance Criteria

Testable but partially manual:
  • tofu plan -lock=false — agent-verifiable immediately
  • kubectl top pod and kubectl describe pod — agent-verifiable post-apply
  • "No OOMKill events for 48 hours" — requires human monitoring or a follow-up check. Not agent-verifiable in a single session. Consider adding a Prometheus query as a concrete check: kube_pod_container_status_last_terminated_reason{reason="OOMKilled", container="repo-server"}

Blast Radius

  • ArgoCD server component (line 82) also has 256Mi limits. If it is also under memory pressure, the same fix pattern would apply. No evidence of OOM on server component currently — not in scope, but worth monitoring.
  • The SOPS CMP plugin sidecar shares the pod's resource context. The sidecar's memory is not separately limited in the Helm values — it inherits from the repoServer resources. The 512Mi limit must cover both containers.
  • No downstream consumers affected — this is a resource limit change, not a behavioral change.

Recommendation

One issue to resolve before READY:
  • Repo mismatch: Either move the Forgejo issue to forgejo_admin/pal-e-services (where the PR will be opened), or create a companion issue on pal-e-services and cross-reference. An agent dispatched against pal-e-platform issue #112 will look for code in the wrong repo.
Minor suggestions (not blockers):
  • Add a Prometheus query to acceptance criteria for the 48-hour OOM check so it can be verified concretely.
  • Note that the SOPS sidecar shares the 512Mi limit — if OOM recurs, the sidecar may be the culprit.