My plan on this:

To replace the client logic, in kubectl rolling-update, a deployment with the same label selector as the old rc and the desired template as the new rc will be generated, and then that deployment will finished the rest of the logic.

If the deployment is already there, just update the deployment's template.

To rollback, just update the deployment's template to the old rc's.

After rolling-update, we don't clean up the generated deployment.

The user experience should not change:

• We should print out scaling up/down events as we do now (We can watch for events and display them)
• The deployment process should stop if users press ctrl C. (Not sure how will we do this)
• The controller should not make any more changes once the process ends (Delete the deployment when deployment.status.replicas=deployment.status.updatedReplicas=deployment.spec.replicas)

IIRC, @bgrant0607 had also suggested that we can introduce a new kubectl rolling-update deployment command and define a new experience there.

The deployment process should stop if users press ctrl C. (Not sure how will we do this)

Setup a listener for SIGINT (https://golang.org/pkg/os/signal/#Notify)

The controller should not make any more changes once the process ends (Delete the deployment when deployment.status.replicas=deployment.status.updatedReplicas=deployment.spec.replicas)

Wouldn't it be more appropriate to set the deployment as inert (first we have to actually support inert) instead of deleting it?

IIRC, @bgrant0607 had also suggested that we can introduce a new kubectl rolling-update deployment command and define a new experience there.

I think this wouldn't be a new command, but rolling-update could support handling deployments.

I think this wouldn't be a new command, but rolling-update could support handling deployments.

Hm, this is the issue in question:) Maybe you are referring to something else... Nvmd

Another candidate is kubectl deploy.

Another candidate is kubectl deploy.

cc: @ironcladlou

kubectl deploy would also be helpful in kicking inert deployments.

@janetkuo did you start working on this? I think you need to use the resource builder with ResourceNames for the first argument (we currently do a simple GET) so we will be able to continue supporting current behavior

$ kubectl rolling-update nginx-1 nginx-2 --image=nginx:v2

but also support flows like

$ kubectl rolling-update deployment/nginx --image=nginx:latest

Thoughts?

Per earlier discussion with @nikhiljindal and @bgrant0607, to support legacy rolling-update behavior with deployment is hard, and instead we can introduce deployment somewhere else, such as kubectl deploy. What's more, kubectl rolling-update doesn't take resource type (it assumes the only resource for rolling-update is rc), so it's another thing to think about if we want to add deployment to rolling-update.

I'll write a proposal for this.

Mainly regarding Deployment history, here are a few more things i need clarification on.

--What is the timeline for getting the deployment history implemented. I need to make something work in the next two months so if this is taking longer than that i would start implementing it on my own.
--for any resource and for Deployment in particular, the way i understand is that resourceVersion is the version of the observed state of the resource and not the desired state. For the desired state of the resource, the versioning is generation, which it seems like is not implemented yet for Deployment resource. Please confirm.

--For deployment version proposal here https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/deploy.md#deployment-version, i don't understand why we are depending on annotations in Replication Controller to track deployment history. RC can be deleted, except the one actively servicing the active pods, i would imagine keeping the deployment history in the deployment object itself may be as annotations. RC is just a construct that is brought up to handle rolling updates if there is only a single RC otherwise it uses an old RC. Thoughts ?Everytime a deployment is successful we can add a annotation to the deployment object and may be use the second highest version or the specified version to roll back. Please help me understand.

@krmayankk I answered your question on google group. Here I paste my answers:

1. This will be included in release 1.2.
2. You're right. generation isn't implemented yet for Deployment.
3. The RCs won't be deleted when you do deployment rolling updates. The replicas of old RCs will only be set to 0. These RCs, which include podTemplate copied from deployment, are seen as snapshots of different versions of the deployment. We want to decouple an object and the objects it creates (a replication controller and its pods is another example). Imagine that a deployment is deleted and then re-created. The deployment will still be able to observe existing RCs and know its deployment history.

The RCs won't be deleted when you do deployment rolling updates.

Depends on the cleanup policy: #19590

Summarize related PRs:

Deployment API:

• Rollback
  • Add version information to deployments (Deployment adds revision info to its new rc #19581)
  • Add deployments/rollback subresource & add rollback logic to deployment controller (Add rollback subresource; add rollback logic to deployment controller #19686) (depends on version information Deployment adds revision info to its new rc #19581)
• Pause/inert deployment (Support pause deployments #18901)
• Perm-failed deployment (Add perma-failed deployments API #19343)

kubectl:

• kubectl rollout (Add kubectl rollout #19882)
  • kubectl rollout undo (Add kubectl rollout undo #19835) (depends on rollback Deployment adds revision info to its new rc #19581 & Add rollback subresource; add rollback logic to deployment controller #19686)
  • kubectl rollout history (Add kubectl rollout history #19893) (depends on rollback Deployment adds revision info to its new rc #19581 & Add rollback subresource; add rollback logic to deployment controller #19686)
  • kubectl rollout pause (kubectl: add rollout pause/resume subcommands #20087) (depends on pause Support pause deployments #18901)
  • kubectl rollout resume (kubectl: add rollout pause/resume subcommands #20087) (depends on pause Support pause deployments #18901)
  • kubectl rollout status (Add kubectl rollout status #19946)
  • kubectl rollout retry (#TBD) (depends on perm-failed Add perma-failed deployments API #19343)

cc @bgrant0607 @nikhiljindal @ironcladlou @Kargakis @kubernetes/sig-config

I can probably do rollout pause and rollout resume after the pause PR is merged. @bgrant0607

I will also do rollout retry later once perm-failed is in.

rollout pause/resume PR: #20087

This is done enough for 1.2, so moving to next milestone.

The main outstanding feature for parity IMO is "kubectl set image".

There's a separate issue for set, and I'd like to wait for user feedback re. status, so closing.