-
Bug
-
Resolution: Won't Do
-
Minor
-
None
-
4.17
-
Quality / Stability / Reliability
-
False
-
-
1
-
Low
-
No
-
None
-
None
-
Rejected
-
NE Sprint 258
-
1
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Description of problem:
As described in https://github.com/openshift/cluster-ingress-operator/pull/1052#issuecomment-2118548732 , the LoadBalancer-type service for TestAllowedSourceRanges has an inexplicable, delayed second update:
2024-05-17T15:07:39.258Z INFO operator.ingress_controller ingress/load_balancer_service.go:321 updated load balancer service {"namespace": "openshift-ingress", "name": "router-sourcerange", "diff": " &v1.Service{
TypeMeta: {},
ObjectMeta: {Name: \"router-sourcerange\", Namespace: \"openshift-ingress\", UID: \"bf35e2d3-bb10-498e-b771-0659315fc65e\", ResourceVersion: \"44908\", ...},
Spec: v1.ServiceSpec{
... // 6 identical fields
SessionAffinity: \"None\",
LoadBalancerIP: \"\",
- LoadBalancerSourceRanges: []string{\"127.0.0.0/8\"},
+ LoadBalancerSourceRanges: []string{\"10.0.0.0/8\"},
ExternalName: \"\",
ExternalTrafficPolicy: \"Local\",
... // 8 identical fields
},
Status: {LoadBalancer: {Ingress: {{IP: \"34.29.9.29\"}}}},
}
"}
2024-05-17T15:25:51.134Z INFO operator.ingress_controller ingress/load_balancer_service.go:321 updated load balancer service {"namespace": "openshift-ingress", "name": "router-sourcerange", "diff": " &v1.Service{
TypeMeta: {},
ObjectMeta: {Name: \"router-sourcerange\", Namespace: \"openshift-ingress\", UID: \"021a0f6b-e316-4d0a-9aaa-15189dded4f6\", ResourceVersion: \"58305\", ...},
Spec: v1.ServiceSpec{
... // 6 identical fields
SessionAffinity: \"None\",
LoadBalancerIP: \"\",
- LoadBalancerSourceRanges: []string{\"127.0.0.0/8\"},
+ LoadBalancerSourceRanges: []string{\"10.0.0.0/8\"},
ExternalName: \"\",
ExternalTrafficPolicy: \"Local\",
... // 8 identical fields
},
Status: {LoadBalancer: {Ingress: {{IP: \"34.16.7.141\"}}}},
}
"}
The second update happens about 18 minutes after the first update. It also happens after the serial tests appear to have finished. I suspect it has something to do with the fact that TestAllowedSourceRanges uses t.Cleanup to delete its IngressController; maybe the cleanup is deleted for that reason, though that doesn't fully explain why the service gets updated a second time (it should just get deleted when the cleanup happens).
Version-Release number of selected component (if applicable):
4.17
How reproducible:
Unknown
Steps to Reproduce:
1.Run TestAllowedSourceRanges
2. Have bad luck
3. Observe a second update in the logs
Actual results:
Second update seen in the logs
Expected results:
Only one update seen
Additional info:
