-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Startup order dependencies problem #748
Comments
Yes, it's a known issue. I've already improved it in the 2.0 branch. Maybe I can backport the improvements. |
Thank you for the fast reply. to start the pods in the correct order, we need to write an kubernetes-operator by our own. Would be great if you could keep me up to date about backporting the improvements. Best, |
Like mentioned by @hylkevds, this is a known issue. That's something that should be extended in the Kubernetes manifest files and the Helm chart. An operator is not needed in this case. It can be solved by using init-containers, that wait until the dependent services are available. If you like, Pull requests are always welcome :-) |
Hi! Unfortunately init-containers only cover the initial startup - but we also observed issues where already running components (HTTP/MQTT) stopped working after others (DB/Message Bus) were restarted for example due to being moved to another node. This could be a different issue though .... Best regards |
Hi,
we are using the FROST-Server (v1.14.0) with kubernetes.
After investigating our last issues, it looks like the pods has to start in the correct order.
If the Mqtt is starting before Database modul or MessageBus does, it failes and never try to reconnect again.
The only way to solve this issue is to restart the pod manually.
Is this a known Problem or wrong configured from our side?
Many thanks in advance.
Best regard,
Marc Beckord
The text was updated successfully, but these errors were encountered: