-
Notifications
You must be signed in to change notification settings - Fork 23
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
Staggered Deploys #82
Comments
If the servos are expendable, would it be better to just deploy the code into a new servo then destroy the old one once the deploy is completed? |
I think most of this discussion should be on internal tools. The only bit that needs to be addressed on this repo is adding support for the flags if/when the feature lands. |
If we're deployed on Modulus for production, we shouldn't bring down our entire API for minutes every time we re-deploy. This is a critical feature. |
Hi @cryptoquick we definitely agree and have zero-downtime deployment on our roadmap to be tackled soon. Thanks for reaching out! |
That's appreciated, thanks... We just went into production this morning, so... I'm really not sure if I'm comfortable having API downtime on each deployment, especially when working with CI. |
@tzmanics Any news on this or maybe an ETA? |
Hi @troxler, we have zero-downtime deployment on schedule for release this quarter. We'll keep you updated to when the release happens. |
@tzmanics Great! Thanks for the update. |
Add the ability to stagger deploys. Deploy 1/2 the servos, wait some period of time, then deploy the other half. This is intended to provide a quick solution for zero downtime deploys.
I discussed briefly with Jack and the medusa implementation should be pretty straight forward. When it queue's up the deploys (in Kue), it can queue half of them with a delayed start.
Possible UX could be:
$ modulus deploy --staggered=30
30 is the number of seconds to wait. If no time is specified default to 5 seconds.
The text was updated successfully, but these errors were encountered: