-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: