search

tryretool / retool-helm

MIT License
45 stars 57 forks source link

Support setting startupProbe #91

Closed plumdog closed 9 months ago

plumdog commented 1 year ago

I'm seeing the main-backend pod take ~2.5 minutes before becoming ready. Currently, I need to therefore set livenessProbe.initialDelaySeconds to something like 180 or more, to ensure the pod isn't deemed to have failed a liveness check before it is ready.

I have the pod running tryretool/backend:2.117.3, requests and limits set to 1vCPU, 2Gi memory.

The Kubernetes solution to this is a startup probe, see https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes

(Alternatively, if it is not expected that the pod takes this long to become ready, what should I do to investigate? I'm using chart retool-wf:4.11.11 from https://charts.retool.com.)

eltioemil commented 1 year ago

@plumdog this happens to me too since I upgraded to 2.117.X. I opened a internal ticket to retool support asking for the same thing you did. In my case it is a bit less time than you but I have the double on resources than you. But, it's still quite slow as it looks like retool waits for all workers to start before exposing the checkHealth endpoint. So the startup probe would be a nice thing to have in the chart.

eltioemil commented 1 year ago

@kyle-retool @JatinNanda I opened a PR with the change, which is fairly simple. Whenever you have time could you please consider it?

Thanks!

eltioemil commented 1 year ago

@plumdog they fixed this here

plumdog commented 9 months ago

And I see that change made it back into this repository in #109 which was first released in 5.0.7.