-
Notifications
You must be signed in to change notification settings - Fork 24
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
Change for deployment rollout #8
base: master
Are you sure you want to change the base?
Conversation
Hi Valdir thanks for your pr, but what if user only has a pod object? |
One option would be to implement an alternative for him to configure via POD or Deployments. Thus, it started to work only with deployments, which ensures that the service does not go down. |
If you can add pod restart , I would like to merge this pr. |
I don't think synator should restart or redeploy anythings. Restarting on secret/config update is a general problem that should be solved by a separate operator (or, ideally, kubernetes itself). |
I created synator because K8s can't do this. |
@TheYkk Then you should create another controller called, eg, "Rystartor" which handles restarting of pods/deployments. It would have nothing to do with Synator and would track both automatic and manual changes to ConfigMaps and Secrets. Why do you think putting two unrelated pieces of functionality into the same controller is a good idea? |
Hello, for my project it made more sense to do with deployments so that the service is not unavailable.