Aborting deploys

[jeroenvisser101]

I think it should be possible to do the following:

1. Abort a deploy while the builder is building the image (seems impossible)
2. Abort (and rollback) while the application is partially rolled out
3. Abort when the first node can't be deployed because health checks are failing (iirc, this isn't being done right now) (this should be fixed in fix(scheduler): rollback scale / deploy when the desired number of pods can not be brought up in a timely manner controller#792, thanks @helgi)

In the worst case, you don't want to wait until a faulty commit has been fully deployed before you can roll it back.

I would love to hear thoughts on this. Thanks!

[helgi]

deis/controller#792 addresses 3) for RCs and when Deployments lands (and people enable that) that is also the default way it behaves (part way due to Deployments themselves)

[kmala]

regarding the point 1 if you are talking about the stopping a git push deis master we had tried that but it is not possible as the git client doesn't send any signals or interrupts while aborting it(CTRL+C).

[bacongobbler]

we had tried that but it is not possible as the git client doesn't send any signals or interrupts while aborting it(CTRL+C).

To elaborate on this, we perform the build operation during git's pre-receive hook. Aborting the git push won't send a signal to the hook because it has no attached connection to the user. The user invokes an SSH session when they run git push deis master, but that session is not attached to the user's keyboard in any way.

[jeroenvisser101]

deis/controller#792 addresses 3) for RCs and when Deployments lands (and people enable that) that is also the default way it behaves (part way due to Deployments themselves)
– @helgi

Thanks, I think that solves that point indeed!

regarding the point 1 if you are talking about the stopping a git push deis master we had tried that but it is not possible as the git client doesn't send any signals or interrupts while aborting it(CTRL+C).
– @kmala

Thanks for the explanation. It makes sense to me indeed, although it's a pity. I guess checking if a connection is still open would be a workaround, but I don't think that implementation would be really nice.

To elaborate on this, we perform the build operation during git's pre-receive hook. Aborting the git push won't send a signal to the hook because it has no attached connection to the user. The user invokes an SSH session when they run git push deis master, but that session is not attached to the user's keyboard in any way.
– @bacongobbler

Thanks for the backstory on this, appreciate all of your input on this!

[bacongobbler]

Closing as these are design issues that we cannot resolve at this time due to how Workflow's infrastructure is set up.

[jeroenvisser101]

@bacongobbler although sad, I understand completely. I asked Heroku as well, and they don't support this either (so they haven't thought about any way to do this either).

Maybe some day Git hooks will be allowed to be interactive. Till then, we'll be extra careful :)