You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my opinion, if I redeploy with the same toml configuration, weaver should basically do a rolling update with no downtime.
If not, please correct me.
So, currently I have implemented the health check API in the form of "GET /".
And actually, the old version of the deployment is going down based on the health check.
The problem is that switching between versions of the server is not done non-disruptively.
A load balancing error occurs for a while as above.
What could be the problem?
Thanks for pointing this out, this is a known issue. As far as we can tell, we're updating the external load-balancer gradually and with the right set of traffic shares, but it does error out for a brief period of time during the traffic change.
We're working on resolving this issue. And you're right, the intention is that you just set the rollout period in your configuration file and the framework ensures that the new version is deployed gradually and safely, without any service interruption.
Rolling update doesn't work well in gke.
In my opinion, if I redeploy with the same toml configuration, weaver should basically do a rolling update with no downtime.
If not, please correct me.
So, currently I have implemented the health check API in the form of "GET /".
And actually, the old version of the deployment is going down based on the health check.
The problem is that switching between versions of the server is not done non-disruptively.
A load balancing error occurs for a while as above.
What could be the problem?
The text was updated successfully, but these errors were encountered: