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: We generally ask for boolean fields to be "in the affirmative direction", as in this case. Now, we could revisit this. It would be a significant change in direction, but it's not impossible. But I don't think that solves your problem in general -- if this field were optional string, with a default value of "Hello there", you would be in the same boat right?
So the underlying issue is that we are defaulting into the PodSpec which gets adopted into all of the PodTemplateSpecs of every object. That sort of defaults the users declared intent. Why not just default the value into the Pod itself . Is the intention really to default this in all Templates or to make it optional in the Template and default it in the Pod itself?
/milestone v1.13
I can't speak to the ideology of whether to default the field in all PodSpecs or just the Pod, but your suggestion makes sense to me. I'm not sure of the past reasoning for adding other defaulted fields, most recently SchedulerName in Jan. 2017 (), to all PodSpecs instead of just to the Pod object. Did we not have these same tests in place then? This would effectively be saying we should never add new defaulted fields to PodSpec. If this is the plan, I can create a PR for the fix and I'll add a big warning comment to SetDefaults_PodSpec.
As an example of where we don't default the template we have a CronJob that embeds JobTemplate, we never default that template, only an actual Job gets defaulting. I agree with that not defaulting any templates does make sense.
Agree to only default this in pods. Agree to adding the comment. Most important defaulting happens in pods to keep higher level pod specs simpler. We may need to raise the general pattern in a discussion with api review in general, since this is a change from previous strategy, but the previous strategy was not explicitly chosen (to my recollection at least)
Hi all do we have an agreed path forward for fixing this issue in 1.13? if so can we have an ETA for the fix to land? the release team would like for the tests to get passing in the blocking suites in an effort to unmask any other failures that might show up once these are fixed.