-
Bug
-
Resolution: Done
-
Normal
-
None
-
4.13, 4.12, 4.11, 4.10, 4.9, 4.8
-
None
-
Low
-
None
-
Sprint 231, Sprint 232
-
2
-
Rejected
-
False
-
-
-
Bug Fix
-
Done
Description of problem:
The function desiredIngressClass doesn't specify ingressClass.spec.parameters.scope, while the ingressClass API object specifies "Cluster" by default. This causes unneeded updates to all IngressClasses when the CIO starts. The CIO will fight with the API default any time an update triggers a change in an IngressClass.
Reference: https://github.com/kubernetes/api/blob/master/networking/v1/types.go#L640
Version-Release number of selected component (if applicable):
4.8+
How reproducible:
Steps to Reproduce:
We really need https://issues.redhat.com/browse/OCPBUGS-6700 to be fixed before we can identify these spirituous updates. But when it is fixed:
# Delete CIO oc delete pod -n openshift-ingress-operator $(oc get -n openshift-ingress-operator pods --no-headers | head -1 | awk '{print $1}') # Wait a minute for it to start back up # Should be NO updates to IngressClasses oc logs -n openshift-ingress-operator $(oc get -n openshift-ingress-operator pods --no-headers | head -1 | awk '{print $1}') -c ingress-operator | grep "updated IngressClass" # Instead, we see this every time CIO starts up 2023-01-26T20:57:15.281Z INFO operator.ingressclass_controller ingressclass/ingressclass.go:63 updated IngressClass {"name": "openshift-default",
Actual results:
2023-01-26T20:57:15.281Z INFO operator.ingressclass_controller ingressclass/ingressclass.go:63 updated IngressClass {"name": "openshift-default", ...
Expected results:
No update to ingress upon CIO restart
Additional info:
- blocks
-
OCPBUGS-34110 [Backport 4.12] The ingress-operator spuriously updates ingressClass on startup
- Closed
- is blocked by
-
OCPBUGS-6700 Cluster-ingress-operator's updateIngressClass function logs success message when error
- Closed
- is cloned by
-
OCPBUGS-34110 [Backport 4.12] The ingress-operator spuriously updates ingressClass on startup
- Closed
- links to