thanks for the great repro! i think adding

waitForJobs: true

to your release should do the trick. this is unfortunately one of those things that (IMO) should probably be the default behavior, but changing it would impact a lot of existing resources so we have to live with it as-is.

thanks Bryce 🙂 im getting very confused on this one though, because I can get the deployment to work sometimes. I've been able to get the pulumi CLI deployment to work 3 times, even though it usually fails and I've seen the helm CLI deployment fail in the exact same spot (Init:2/3) only once, even though it usually always succeeds I'm stumped 🤔 I added a comment in the redpanda helm chart repo, I think it could be to do with the small cpu/memory limits - perhaps they haven't taken different architectures into account? https://github.com/redpanda-data/helm-charts/issues/1564#issuecomment-2417434595

huh, i must’ve also run into a flake. i’m also using orbstack fwiw but i don’t think that should matter… you could also try

kind

it looks like the issue was primarily coming from the small limits (100m cpu, 25Mi memory), but there are still a few things I don't quite understand, such as • why did the pulumi CLI fail 90% of the time, and the helm CLI deploying the same chart with same values only failed ~10% • the binary in the init container was 80Mb which means the memory limit would have always been breached on each run, I wonder if k8s has implemented limits using a polling strategy, which would allow for a successful deployment to occur only when the container was able to complete between stats polling • in the cases of the failed deployments, why isn't any error being reported? I have a feeling that this might be an orbstack issue where they haven't implemented breached limits handling in init containers