ENH: deploy_service

[patr1ckm]

Write deploy_service that

• deploys the a service if it isn't deployed and blocks until completion
• redeploys the service if it is deployed, and blocks until completion
• Only redeploys if a service isn't currently deploying

Only question is whether trying to redeploy an app that is currently deploying should

1. throw an error and fail
2. generate a warning and skip the redeploy request
3. block until the current deployment has been completed and then continue with the requested redeploy.

I'm leaning toward option 3 so that a user doesn't have to write error handling / signalling / retrying around this state. The risk having a bunch of requests pile up to redeploy the app. I don't think it's a big risk though, it might just be confusing.

@keithing, @skomanduri thoughts?

[keithing]

3 sounds good to me! Out of curiosity, are we able to redeploy in a way that minimizes downtime?

[skomanduri]

@keithing Yes, the redeploy will start a new instance of the app, route traffic to it, and shut down the old instance when the new one is ready. So it is theoretically zero-downtime. However, there is a bug we need to fix before it actually works that way: https://civisanalytics.atlassian.net/browse/CIVP-15342

Also, this requires the client cluster to have enough capacity to run two copies of the app at the same time.

I also like option 3.