-
Notifications
You must be signed in to change notification settings - Fork 88
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
Do not Trigger RolloutRestart with every secret change #644
Comments
@koolhandluke - that's a great suggestion. We have had some internal discussion around its implementation, but currently have no concrete commitment to add it. |
HI @benashz - thanks. The cache period would be the batch deploy interval. it could work like so:
Bonus points for doing it within a given deployment window.. ( not true CD but that is the world some folks live in) |
I am also interested in this feature. In our case, we have a couple of micro-services fetching the same secret. Changing the secret triggers the restart of all micro-services which can cause downtime. |
The RolloutRestart feature is a great feature of the operator.
However, the current implementation can cause outages or service degradation if several secrets are rotated for a given application within a short interval. This would set off a series of "thrashing" restarts.
Could we add a feature to "batch" up restarts for a given target ?
This way it would ensure only 1 rolling restart is executed within that period - eliminating unnecessary pod restarts.
eg the following would do a max of one rolling restart for the " vso-db-demo" deployment per hour.
rolloutRestartTargets:
name: vso-db-demo
deployInterval: "60m"
The text was updated successfully, but these errors were encountered: