Duc NguyenandClaude Opus 5
79c96fb1ee
Repackaged from the exact 2.0.0 tree that was published here (sha256 371cff69...05bcf4); the only difference in the rendered output is the three resources blocks. Every tenant namespace has a ResourceQuota named labelstudioservice-<ns> that requires limits and requests on every container, and the chart left app.resources, app.initContainer.resources and app.nginx.resources empty. Pod creation was rejected outright: pods "studio-vegastar-..." is forbidden: failed quota: labelstudioservice-<ns>: must specify limits.cpu for: db-migrations,nginx; limits.memory for: ... 17 of 22 tenants sit at 0/1 with no pods because of it. The 5 still running were created before the quota took effect and would fail the same way on restart. The quota is requests 200m/512Mi, limits 500m/1Gi - exactly what the app container alone takes, because the KubePlus podconfig webhook only injects resources into the first container. A pod is charged max(sum of regular containers, max init container), so db-migrations does not add to the total. This split fits the existing quota exactly, so no ResourcePolicy or per-namespace quota needs changing: app requests 170m/448Mi limits 400m/928Mi nginx requests 30m/ 64Mi limits 100m/ 96Mi db-migrations requests 100m/256Mi limits 400m/768Mi Sized from live usage on the 5 healthy tenants: app 5-8m CPU and 782-806Mi, nginx 1m and 15-29Mi. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>