Change:
By("creating a third pod to probe DNS") pod3 := createDNSPod(f.Namespace.Name, wheezyProbeCmd, jessieProbeCmd, true) <del> validateTargetedProbeOutput(f, pod3, []string{wheezyFileName, jessieFileName}, "10.0.0.123") </del> <ins> svc, err := f.ClientSet.Core().Services(f.Namespace.Name).Get(externalNameService.Name, metav1.GetOptions{}) Expect(err).NotTo(HaveOccurred()) validateTargetedProbeOutput(f, pod3, []string{wheezyFileName, jessieFileName}, svc.Spec.ClusterIP) </ins> }) })

Discussion:
This e2e test is failing on several of the upgrade tests. https://k8s- https://k8s- https://k8s- /cc
The upgrade tests you listed mean running 1.6/1.7 tests against master clusters, right? was merged after 1.7. Before that PR, clusterIP is not respected when updating from service type ExternalName to type ClusterIP. After that PR, specified clusterIP will be allocated. The IP will be validated when allocating. In the failed tests, is not in the valid clusterIP range of the testing clusters. Maybe we should disable this test case in such upgrade tests? /cc
how to disable a test in upgrade tests?
tried to check with #sig-release or any advice on this?
would it be possible to modify the test to make it pick a valid clusterIP range?
On HEAD, it already picks a valid clusterIP, but I don't how to modify in 1.7/1.6. Maybe by a cherry-pick but I don't know if we want to cherry-pick .
If you can identify the patch that fixes the bug, we could backport. Or we should disable that case.
. But it's somewhat large, I don't think we want to backport it. One alternative is to send a small patch to change below IP to be another valid IP (although it's already a valid IP on HEAD). So we can have a small patch to backport and then we can cherry-pick it to 1.6/1.7. Tim, WDYT?
This test started passing again on the upgrade tests. hmmm. https://k8s-
Hmmm, weird...
Can't find anything in the log explaining why it is not failing anymore. Only thing I can see from comparing two logs artifacts (, ) is the name of sub directories (that I guess is related to notes running the test) is different (and less in success case). Maybe it has something to do with some config changes in running e2e tests.
also comparing image list of files of those two , cases, the success case has way less images (only one actually). I wonder if some change disabled this (or many more) tests?!
Any update on this?

The test is still failing for at least gce-1.7-master-upgrade-master. Should the test being disabled for 1.7 and re-enabled in 1.8?
I take a look at the test failure of . There is only one failure of (the test case associated with this issue) on 08.29 since 08.17. The is as below. It's not the failure in this issue.
As is mentioned in by , the original issue here might be caused by upgrade framework.
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/network: Issue will be escalated to these SIGs if needed. priority/critical-urgent: Never automatically move out of a release milestone; continually escalate to contributor and SIG through all available channels. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
is this still regularly failing? And is the actual issue the upgrade framework, or something actually DNS related?
Going to close since the test is back to green. Will re-open if we see more failures.
And is the actual issue the upgrade framework, or something actually DNS related? Per discussion in , I think it's the issue of upgrade framework.
This is popping up again in some of our other upgrade tests https://k8s- Going to re-open for tracking. It sounds like this is still non-blocking though, so lowering the priority.
/sig testing /area test-infra /assign as per
Found this in : https://k8s- Not sure if this has something to do with the failure. BTW, the below tests have exactly the same failure status when fails. [] CronJob should adopt Jobs it owns that don't have ControllerRef yet [] Initializers should be invisible to controllers by default [] PodPreset should create a pod preset [] PodPreset should not modify the pod on conflict So I think it's most likely an issue of the upgrade framework.
/unassign That's the normal error message from a Ginkgo test failure and has nothing to do with , which has the failure signature of .
/assign xiangpengzhao
I'll track you guys as owners for this failure. Let's try to get it merged quickly.

And let me know if you don't have time/power to fix that. Thanks
Upgrade framework is likely broke by Ref: It is being fixed by
ref:
- does not seem to have v1.8 and this Issue seems to have v1.8, is there a disconnect? ( cc )
I want to be in 1.8 milestone and be cherry-picked to 1.6/1.7.
I it to the 1.8 milestone, but it still needs approvals. Contact about the 1.7.x cherry pick and about 1.6.x
Thanks !
merged, let's wait and see :)
https://k8s- is green!
Unfortunately, gke-gci-1.7-gci-master-upgrade-cluster-parallel still fails after merged. This test has a different clusterIP range . cc https://k8s- PS: helps provide the range info, it's really useful :)
I send PR trying to fix this. PTAL. Thanks!
This is still failing on some 1.8 upgrade tests https://k8s-
do we need to cherrypick the fix into previous branches?
Sorry I forgot to update here. is fixing the gke 1.7-1.8 upgrade cases. I will send a similar fix to 1.6 branch to fix the 1.6-1.8 upgrade cases soon.
Sent for 1.6 branch.
Both fixes are merged, I will observe the upgrade suites a bit longer before closing.
Test is passing now (on both 1.7-1.8 and 1.6-1.8, gce and gke). Closing this issue. /close
Awesome!