Bug 1846507
| Summary: | [sig-network][Feature:Router] The HAProxy router should expose prometheus metrics for a route | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | OpenShift BugZilla Robot <openshift-bugzilla-robot> |
| Component: | Networking | Assignee: | aos-network-edge-staff <aos-network-edge-staff> |
| Networking sub component: | router | QA Contact: | Arvind iyengar <aiyengar> |
| Status: | CLOSED EOL | Docs Contact: | |
| Severity: | medium | ||
| Priority: | medium | CC: | aiyengar, amcdermo, aos-bugs, bbennett, bparees, bperkins, ccoleman, dosmith, hongli, mmasters, wking |
| Version: | 4.5 | ||
| Target Milestone: | --- | ||
| Target Release: | 4.5.z | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-08-03 15:22:15 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1835371 | ||
| Bug Blocks: | |||
The fix has reduced the intermittent flakes quite significantly. Moving to 4.6 and will backport if we can continue to reduce the intermittent nature. https://bugzilla.redhat.com/show_bug.cgi?id=1835371 is the original targeted at 4.6 I think this bug was intended to be a clone that targeted 4.5 and then got its target unset and reset to 4.6, i am setting it to 4.5.z. if you conclude a backport to 4.5.z is not needed, then close this bug. (In reply to Ben Parees from comment #8) > https://bugzilla.redhat.com/show_bug.cgi?id=1835371 is the original targeted > at 4.6 I think this bug was intended to be a clone that targeted 4.5 and > then got its target unset and reset to 4.6, i am setting it to 4.5.z. > > if you conclude a backport to 4.5.z is not needed, then close this bug. IIRC, in our bug scrub the intent was to move it out of 4.5[.0]. A backport to 4.5.z is still needed. I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint. I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint. I’m adding UpcomingSprint, because I was occupied by fixing bugs with higher priority/severity, developing new features with higher priority, or developing new features to improve stability at a macro level. I will revisit this bug next sprint. We need to figure out whether https://github.com/openshift/router/pull/179 fixed or arrested the flake rate in 4.6. If so, we will consider a backport. Tagging with UpcomingSprint. Tagging with UpcomingSprint while investigation is either ongoing or pending. Will be considered for earlier release versions when diagnosed and resolved. Tagging with UpcomingSprint while investigation is either ongoing or pending. Will be considered for earlier release versions when diagnosed and resolved. Tagging with UpcomingSprint while investigation is either ongoing or pending. Will be considered for earlier release versions when diagnosed and resolved. OCP 4.5 is out of support now, there will not be any more releases for 4.5 Please see lifecycle policy https://access.redhat.com/support/policy/updates/openshift for supported versions. |
We can continue to see intermittent failures in the recent runs post the PR merge. With below errors: --- fail [github.com/openshift/origin/test/extended/router/metrics.go:189]: Expected <[]float64 | len:2, cap:2>: [0, 0] to consist of <[]interface {} | len:2, cap:2>: [ {Comparator: ">", CompareTo: [0]}, {Comparator: ">", CompareTo: [0]}, ] --- There are certain times in the run when the test seem to work perfectly. Is this occurrence still a problem with e2e test or due to some anomalies in the environment.