openab helm chart analysis report

[masami-agent]

OpenAB Helm Chart Analysis Report

Date: 2026-04-17

Executive Summary

OpenAB Helm chart (v0.7.7) is a purpose-built, single-concern chart that does exactly
what it needs to do — deploy ACP agent pods bridging Discord/Slack to coding CLIs.
The "simplicity" observation is largely a compliment, but there are a few areas where
the chart could mature without losing its lean character.

---

Chart Inventory

File	Lines	Purpose
Chart.yaml	6	Metadata (apiVersion v2, type: application)
values.yaml	~140	Multi-agent config with sensible defaults
_helpers.tpl	~70	Name/label/image helpers
deployment.yaml	~110	Per-agent Deployment (range loop)
configmap.yaml	~120	Per-agent config.toml + optional AGENTS.md
secret.yaml	~35	Discord/Slack/STT tokens
pvc.yaml	~25	Per-agent PersistentVolumeClaim
NOTES.txt	~60	Post-install instructions
Total	~570	6 templates + helpers + notes

For comparison, a typical "simple" community chart (e.g. Bitnami Redis) has 20-40 template
files and 1000+ lines of values.yaml.

---

What the Chart Does Well (Why "Simple" = Praise)

1. Single-Concern, Zero Bloat

The chart deploys exactly one resource type per agent: Deployment + ConfigMap + Secret + PVC.
No Service, no Ingress, no HPA, no ServiceAccount, no NetworkPolicy — because the app
doesn't need them. It's a long-running WebSocket client, not a server. This shows the
author understands the workload.

2. Multi-Agent via Range Loop

The {{- range $name, $cfg := .Values.agents }} pattern is elegant. One chart install can
deploy N agents, each with independent config, secrets, and storage. This is a design choice
that many charts with 10x the code don't achieve.

3. Strong Input Validation

The configmap template includes regexMatch guards against float64 precision loss on
Discord/Slack IDs, with clear fail messages. This is a real-world footgun that most charts
ignore entirely. The allowBotMessages enum validation is also a nice touch.

4. Security Defaults

podSecurityContext:
  runAsNonRoot: true
  runAsUser: 1000
containerSecurityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop: [ALL]

Non-root, no privilege escalation, all capabilities dropped. This passes most Pod Security
Standards (restricted profile) out of the box.

5. Practical NOTES.txt

Post-install notes include per-agent auth commands for 6 different CLI backends (kiro, claude,
codex, gemini, opencode, cursor). This is genuinely helpful UX.

6. Config Checksum for Auto-Restart

annotations:
  checksum/config: {{ $cfg | toJson | sha256sum }}

Config changes trigger pod recreation automatically. Simple and effective.

7. Secret Resource Policy

annotations:
  "helm.sh/resource-policy": keep

Secrets survive helm uninstall. Good for protecting bot tokens from accidental deletion.

8. Multi-Platform Adapter Support

Discord and Slack adapters with independent enable/disable, plus STT (speech-to-text)
integration. The chart handles the combinatorial complexity cleanly.

---

What's Genuinely Missing (Where "Simple" = Gap)

1. No Health Checks (Liveness/Readiness Probes)

Severity: Medium-High

The Deployment has zero probes. If the openab process hangs (e.g. WebSocket stall),
Kubernetes won't restart it. For a 24/7 Discord bot, this is a real operational risk.

Recommendation:

livenessProbe:
  exec:
    command: ["/bin/sh", "-c", "pgrep -f openab"]
  initialDelaySeconds: 10
  periodSeconds: 30
readinessProbe:
  exec:
    command: ["/bin/sh", "-c", "pgrep -f openab"]
  initialDelaySeconds: 5
  periodSeconds: 10

Or better: add a /healthz HTTP endpoint to the openab binary.

2. No ServiceAccount

Severity: Low-Medium

The chart uses the default ServiceAccount. Best practice is to create a dedicated
ServiceAccount with automountServiceAccountToken: false since the pod doesn't need
K8s API access.

3. No Resource Requests/Limits by Default

Severity: Medium

resources: {} means no QoS guarantees. On a shared cluster, one runaway agent could
starve others. On a single-node Mac mini this is less critical, but still good practice.

Recommendation: add sensible defaults in values.yaml:

resources:
  requests:
    cpu: 100m
    memory: 256Mi
  limits:
    memory: 512Mi

4. No Pod Disruption Budget

Severity: Low

With replicas: 1 and strategy: Recreate, there's a brief downtime window during
upgrades. A PDB wouldn't help here (can't have minAvailable=1 with 1 replica), but
documenting the expected downtime behavior would be good.

5. No Helm Schema Validation (values.schema.json)

Severity: Low-Medium

There's no values.schema.json to validate user input at helm install time. The
template-level fail calls partially compensate, but a JSON schema would catch typos
and type errors earlier.

6. No RBAC / NetworkPolicy

Severity: Low

The pod doesn't need K8s API access or inbound traffic, so the absence of RBAC and
NetworkPolicy is defensible. However, a deny-all ingress NetworkPolicy would be a
nice hardening layer.

7. No Horizontal Scaling Story

Severity: Low (by design)

The chart hardcodes replicas: 1 with a comment explaining why (RWO PVC). This is
correct for the current architecture. If scaling is ever needed, the multi-agent
range loop already provides horizontal scaling at the agent level (deploy more agents).

---

Verdict: Compliment or Criticism?

Aspect	Assessment
Architecture fit	✅ Chart matches workload perfectly
Template quality	✅ Clean, well-structured, good helpers
Input validation	✅ Above average for community charts
Security posture	✅ Strong defaults
Multi-agent design	✅ Elegant range-loop pattern
Operational maturity	⚠️ Missing probes, resource defaults
Production hardening	⚠️ No ServiceAccount, no NetworkPolicy
Developer UX	✅ Great NOTES.txt, clear values.yaml

Bottom line: This chart is "simple" in the way a well-designed Unix tool is simple —
it does one thing and does it well. The ~570 lines cover a surprisingly complete feature
set (multi-agent, multi-adapter, PVC, secrets, validation, auto-restart).

The gaps (probes, resources, ServiceAccount) are the kind of things you add when moving
from "works great on my Mac mini" to "runs in a shared production cluster." They're
normal for a project at this stage.

The expert's comment is more compliment than criticism. The chart avoids the common
trap of over-engineering with features the workload doesn't need. The areas for improvement
are incremental hardening, not architectural problems.

---

Priority Improvements (If You Want to Level Up)

1. Add liveness/readiness probes — biggest operational win
2. Set default resource requests — prevents noisy-neighbor issues
3. Create a dedicated ServiceAccount — security best practice
4. Add values.schema.json — better UX for chart consumers
5. Add deny-all ingress NetworkPolicy — defense in depth

[github-actions]

Thanks for the report! It looks like this issue was created without a template and is missing some required fields. Please add one of the following labels: bug, feature, documentation, or guidance, then edit this issue to include the matching template fields — the incomplete label will be removed automatically.

[thepagent]

Thank you for the report!