mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-03 18:47:04 +09:00
IvanHunters
41aed829e6
## What Raise the `kafka` and `zookeeper` components in the Kafka e2e test from the `nano` preset (250m / 128Mi) to `c1.small` (1 CPU / 1Gi), the chart default. ## Why 128Mi cannot hold the Strimzi Kafka 3.9.1 and ZooKeeper JVMs. The brokers OOMKill on startup (exit 137) and enter CrashLoopBackOff, so the pods never reach Ready, the `Kafka` CR and its HelmRelease never go Ready, and the 5m readiness wait times out. It presents as a flake rather than a hard failure because 128Mi sits right at the JVM-start threshold — occasionally a broker becomes Ready before its RSS crosses the cgroup limit. `c1.small` (1Gi) comfortably fits both JVMs and matches the chart default, so the test exercises the documented default sizing. The e2e sandbox VMs are 8 CPU / 24Gi, so 1Gi per pod (4Gi total) across the four pods (kafka-0/1, zookeeper-0/1) is well within budget. ## Scope Test-only; values changed, test structure untouched. MariaDB's e2e test also uses `nano` but was deliberately left as-is: it runs MariaDB (C) + a Go exporter with no JVM, its chart default is already `t1.nano` (128Mi), and it shares the `nano` preset with the passing postgres/redis/qdrant tests — not the same OOM class.