kubectl rolling-update should not exitcode=0 when resumes an update

[justinsb]

Consider this:

> kubectl rolling-update A --image a:v2

Control-C half way through update

> kubectl rolling-update A --image a:v3
Found existing update in progress (X), resuming.
Continuing update with existing controller (X).
Update succeeded. Deleting old controller: X
Renaming X to X

So the update to v3 succeeded (I think), but the update was actually to v2.

I think it should update to v3; ideally by co-opting the existing rolling-update and repointing to v3. If we can't do that, it should completing the existing rolling-update, then rolling-update to v3. If we can't have that, it should exit-code != 0.

[bgrant0607]

This is what I call "rollover". There are actually 3 versions in play in the above scenario: v1, v2, and v3. Each requires its own template, and thus its own replication controller. If the update were killed and restarted again with v4, that would be 4 versions/RCs. We'd need to change the way we keep track of the set of RCs that need to be replaced in order to handle this. Background is in #1353.

In the meantime, we should issue an error in the case that the image doesn't match.

[JasonGiedymin]

Based on the requirements and mostly the comments, I thought that a cancel such as this should trigger a stop pause and let me rollback. I'd expect that a re-issue to v3 take me from 1 to 3 (since I did cancel a v2 update), or force me to make a choice. That resolution is important because the state of my replicas as defined (say I had a min count) would be inconsistent from a configuration management point of view. Trying to understand more about the issue and contribute.

[bgrant0607]

Rollback is supported, via --rollback: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/kubectl_rolling-update.md