-
Notifications
You must be signed in to change notification settings - Fork 87
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
blue green strategy: add delay before deleting venerable app #569
base: main
Are you sure you want to change the base?
Conversation
DefaultBindTimeout = 5 * time.Minute | ||
DefaultStageTimeout = 15 * time.Minute | ||
DefaultAppPort = 8080 | ||
DefaultBlueGreenPostStartupWaitTime = 10 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should set it to 0 by default in order for it to not impact people who don't want it
@Cocossoul could you describe this flag in the documentation as well? Otherwise LGTM 👍🏻 |
@Cocossoul I'd say make sense to have this default to 0, and only enable for the applications needing the extra time. However, I have one concern, the applications should not have returned a successful healthcheck until it's really ready to service traffic. If the applications returned it's correct healthcheck status, you should not have this scenario where the venerable app is destroyed before the green version of the app is ready. The extra time each application needs will be hard to gauge. The setup time may vary between landscapes, locations, regions, and app versions. Tracking and maintaining this delay will add technical debt and overhead to the teams. Hardcoding it to large values and setting it once might seem like a solution, but it results in two copies of the app running, consuming costs and quotas. In large deployments, one application can have over 100 instances, each with 8GB of memory. Doubling this amount will significantly impact the quota available for other applications. It is preferable to delete the old app immediately once the new app is ready. |
Some apps can take a few moments to be fully up even after Cloudfoundry declared them "started" : database schema migrations, establishing connections to clients...
We had some reports of downtime because the venerable app was deleted when the new app was not fully "started" (even if Cloudfoundry was showing it started : it's not a bug in Cloudfoundry more like a practical issue on our side)
The workaround we have found is to add a preconfigured delay before killing the venerable app, and I think it can be useful to other in our case.