Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
support delay before history joins membership (#4582)
<!-- Describe what has changed in this PR --> **What changed?** When a history instance starts, support a configurable (defaulting to zero) delay before joining membership. <!-- Tell your future self why have you made these changes --> **Why?** In environments where the history service is running via a Kubernetes Deployment, rolling restarts or image upgrades cause considerable shard movement, because the Deployment will simultaneously terminate one pod & create a new one. By configuring a non-zero delay on the order of seconds, the shard movement due to the terminating pod can be separated from the shard movement of the newly created pod. Overall, this reduces the impact to user api calls during the change. <!-- How have you verified this change? Tested locally? Added a unit test? Checked in staging env? --> **How did you test it?** This has been tested in a staging environment. <!-- Assuming the worst case, what can be broken when deploying this change to production? --> **Potential risks** With the default setting of zero, no risk. <!-- Is this PR a hotfix candidate or require that a notification be sent to the broader community? (Yes/No) --> **Is hotfix candidate?**
- Loading branch information