cc @ghodss @ironcladlou

Labelling this PR as size/XS

GCE e2e build/test passed for commit 8e94a07.

• Build Log
• Test Artifacts
• Internal Jenkins Results

What's the use case for having them be different?

I sent this as a separate PR to get everyones view on should we allow users to change labels while they are deploying a new RC.
For ex: to change the label from tier:beta to tier:ga when they update the image from 0.9 to 1.0.

cc @bgrant0607 @smarterclayton

Wouldn't that prevent the deployment object from being able to select the right pods to scale down the previous deployment?

Although, if that's the case, how would someone actually change the labels of an existing deployment object and its pods?

Deployment.Selector will determine the old pods that should be scaled down.
Deployment.Spec.PodTemplateSpec will determine the RC that should be scaled up.

Deployment.Selector does not need to be same as Deployment.Spec.PodTemplateSpec.Label.

Changing the labels of a deployment will have no effect on any other RC or pod.
With this change, we will allow users to create a deployment to update labels of a pod (for which I am asking if it is a valid use case to support)

If Deployment.Selector is not the same as Deployment.Spec.PodTemplateSpec.Label, does that leave open the possibility that you could have a runaway deployment controller which creates infinite replication controllers because they never match the deployment object? Perhaps they don't need to be equal, but they must at least match?

GCE e2e build/test passed for commit 8e94a07.

• Build Log
• Test Artifacts
• Internal Jenkins Results

I think updating the pod labels is a valid use case - we've actually had it come up several times. I have a deployment Foo that uses label a=b. I want to shard Foo. I edit and deploy Foo to use label a=b,shard=1, then create Bar, which uses label a=b,shard=2. So I see editing pod labels over the lifetime of a deployment as required unless we want people to delete their existing deployments and recreate them (seems bad)

I don't understand the logic behind this change. The selector MUST match the labels in the pod template. The pod template labels can either be changed in a way that they don't alter that property, or the selector can be changed to match the new labels. In the latter case, the question then is what Deployment does about the "orphaned" RCs and pods, and how it finds them.

Discussed offline: This is not the right way to solve this problem.

#14894 details a possible solution