@bgrant0607 A clarification: The knob the decides what happens to orphaned RC (left as is or is scaled down) is with the RC or the deployment that orphaned it?

Will comment later. This won't go into 1.1.

Yes. Sorry, I should have mentioned that.

The knob to control the result after orphaning should be on the deployment I think, because a) it's centralized and can be changed in one place (likely user intent) and b) if you want to control it on a per RC basis, you can already do so in the proposal by clearing the ref from RC to deployment (at which point the deployment policy no longer applies)

One weird thing to me is that by changing the label, you get different deployment behavior: I've configured a deployment for rolling updates, and I need to change a label in the selector. The deployment for the label change won't be rolling and could violate my availability requirements (new one is scaled up right away, old one is GC'd somehow by another controller later.)

Maybe I'm missing the use cases for label changes. Would it be surprising that the deployment mechanics will be totally different when changing label values in the selector?

controllerRef proposal: #2210 (comment)

Overall controller pod management: #14961

I don't think we need a different controller to do deletion of orphaned pods.

@ironcladlou has a good point.

The main use case is adding labels and to the selector to match, probably because the user wants to differentiate the deployment from another they plan to create. The "simple rolling update" implementation does this to add a deployment label, for instance. Adding a 2nd shard is another possible scenario.

What the user probably wants is the new selector to be used for the new RC, but the old ones to be spun down as with any rolling update.

If the template labels and selector are the only changes, we could eventually do an in-place udpate #9043, like in "simple rolling update".

Isn't it a different logical controller loop? We need to reconcile the set
of RCs or Pods to the set of valid Deployments instead of vice versa?

On Oct 2, 2015, at 5:45 AM, Brian Grant notifications@github.com wrote:

controllerRef proposal: #2210 (comment)
#2210 (comment)

Overall controller pod management: #14961
#14961

I don't think we need a different controller to do deletion of orphaned
pods.

—
Reply to this email directly or view it on GitHub
#14894 (comment)
.

See also #36897

What is described in the initial post is already implemented - once a Deployment is not matching a set of ReplicaSets because it has a different selector, those ReplicaSets are released (owner refs are removed). If there is anything else we need to do on this issue, please reopen it.