Change:
for _, cmdGroup := range t.cmdGroups(c, c.Commands()) { cmds := []string{cmdGroup.Message} for _, cmd := range cmdGroup.Commands { <del> if cmd.Runnable() { </del> <ins> if cmd.IsAvailableCommand() { </ins> cmds = append(cmds, "  "+rpad(cmd.Name(), cmd.NamePadding())+" "+cmd.Short) } }

Discussion:
Rolling-update tasks which worked since v1.0 are now getting stuck mid-way since v1.2 I'm rolling a multi-container pod from to . The target number of replicas is 4. The first 2 pods are rolled correctly, but the job hangs and times out (5min) after the first 2 iterations: Controller manager logs: Note the time it took to scale down on the second iteration, although all the pods marked new transitioned to a state in less than 10sec. My RC selector matches 3 labels. After the timeout the 2 RCs look like:
Can you please share the exact command you are running that leads to timeout? cc
I first get the current RC definition in YAML format, replace the image tag and label, and finally pass it to:
Were you able to reproduce this consistently (i.e. this always fail)?
Yes, 100%. It eventually goes through if I increase the timeout but I still have to wait a couple of minutes between each pod. I switched this deployment task to the API with the Rolling-update strategy and it's extremely fast.
Yes, we'd recommend using  since it's faster, declarative and has more features, such as you can rollback to a previous reversion even when the rollout/rolling-update is done. When you're using , is it possible that there are overlapping resources fighting with , such as replicasets, deployments, or replication controllers with the same label selector?
labels are not conflicting. I have 2 other rcs in that namespace and each of them has a different label (see my first comment). Nothing has changed in that deployment procedure since Kubernetes v1.0, and v1.2 is the first version that seems to struggle. I can post my rc definition here, just in case you can't reproduce with a generic 3-container pod.
Yes, posting the RC definition would help, since I cannot reproduce it on my end. Thanks!
The following definition times out as described above. It resembles our real definition, minus a log forwarding container which I replaced by something generic like postgres.

Secrets: Create the rc and secrets: Now delete the rc without killing the pods: In the definition, rename the rc to anything else, and recreate it: In the definition, rename the rc back to the original name "issue23276" and bump the "deployment" number in the label, then perform a rolling-update: It remains stuck in this state:
cc
Quick observations: In 1.1 and 1.2, rolling update takes pod readiness into account before proceeding. Are the pods ready? Use "kubectl get -o yaml pod ...". Cpu limits are now enforced using cpu quota and 10m is a very small limit. Specify "requests" instead.
In and specifically refererring to , it seems that this pod is never scaled down (based on the following output from . Can you inspect the container logs from the old pods for anything weird?
This limit is low on purpose, this container only starts . In our production environment we use it for log rotation with the same CPU limits. When deployed using the API everything works and the rolling update takes less than a minute. All pods are running as expected and don't show any error.
Same problem here. We don't use any limits, but simple scale down more then 3 pods is hangs. One moment about rolling-update issue: it appears only in case of renaming original rc; if use it by default all ok.
should help in identifying if the error comes from the scaler.
Must add to message, that with bigger time-out (--timeout=30m), rolling-update proceeds after 3 pods but much slower. On master I have following log for 5 pods RC: Message like appear every time before update makes progress after a ~5 minutes freeze.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
/sig cli
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or .

/lifecycle stale
We should consider deprecating the rolling-update command.
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close