Code change:
// DeepEqualSafePodSpec returns a PodSpec which is ready to be used with apiequality.Semantic.DeepEqual func DeepEqualSafePodSpec() api.PodSpec { grace := int64(30) <del> enableServiceLinks := v1.DefaultEnableServiceLinks </del> return api.PodSpec{ RestartPolicy:                 api.RestartPolicyAlways, DNSPolicy:                     api.DNSClusterFirst, TerminationGracePeriodSeconds: &grace, SecurityContext:               &api.PodSecurityContext{}, SchedulerName:                 api.DefaultSchedulerName, <del> EnableServiceLinks:            &enableServiceLinks, </del> } } // V1DeepEqualSafePodSpec returns a PodSpec which is ready to be used with apiequality.Semantic.DeepEqual func V1DeepEqualSafePodSpec() v1.PodSpec { grace := int64(30) <del> enableServiceLinks := v1.DefaultEnableServiceLinks </del> return v1.PodSpec{ RestartPolicy:                 v1.RestartPolicyAlways, DNSPolicy:                     v1.DNSClusterFirst, TerminationGracePeriodSeconds: &grace, SecurityContext:               &v1.PodSecurityContext{}, <del> EnableServiceLinks:            &enableServiceLinks, </del> } }

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug The change in a new field () to the Pod spec that is set to true by default. This is causing problems for DaemonSets in some situations. DaemonSets are using ControllerRevisions to keep track of previous configurations and each revision will contain among other things the Pod spec for the DaemonSet. If a DaemonSet is created with the enableServiceLinks property is set to true, the ControllerRevision will also contain this field. If the cluster is rolled back to a previous version of kubernetes, the DeamonSet struct does not have this field and so the ControllerRevision and the DaemonSet will no longer match. This leads to a new ControllerRevision being created and a rolling update of all pods in the DaemonSet. Would it be a better solution to rename the field to and enable service links whenever the field is not set? This would fix the problem with the DaemonSets unless the field is explicitly set before the rollback. This is causing the master upgrade tests to fail as reported in /sig apps /cc /cc /cc
I guess the change in podSpec and the defaulting will break all the workload resources as they are based on comparing the template's podSpec. ~Is the new value defaulted to true also for the DaemonSet's podSpec template? If not, controller might go hot loop like with mutating admission controllers.~ I don't like us making such changes to v1 podSpec. The other way around seems more sensible. /cc
Why is this a bad thing? We will continue to add fields to podSpec - the issue isn't the defaulting (this would happen regardless of which way it defaulted), it's that the controller can't really be version aware. The new value would default to true in the daemonset as well.
I'm not sure that a rollback requiring daemonsets to recreate is a bug. I think that's potentially "the best possible thing that we can do in that case".
/cc SIG Release blocking dashboard with upgrade test failures - https://k8s-
So the problem isn't the fact that a field has been . It the way in which the field was .