-
Bug
-
Resolution: Done-Errata
-
Normal
-
4.11.z
-
None
-
Moderate
-
No
-
MON Sprint 242
-
1
-
False
-
-
NA
-
Release Note Not Required
-
In Progress
Description of problem:
I'm seeing Prometheus disruption failures in upgrade tests
Version-Release number of selected component (if applicable):
How reproducible:
Sporadically
Steps to Reproduce:
1. 2. 3.
Actual results:
Expected results:
Additional info:
- links to
-
RHEA-2023:7198
rpm
-
RHSA-2023:5006
OpenShift Container Platform 4.14.z security update
[OCPBUGS-18141] disruption_tests: [sig-instrumentation] Prometheus metrics should be available after an upgrade failing
Junqi Zhao
added a comment - searched upgrade to 4.15 tests
https://search.ci.openshift.org/?search=Prometheus+metrics+should+be+available+after+an+upgrade&maxAge=168h&context=1&type=bug%2Bjunit&name=4.15.*-upgrade.*&excludeName=&maxMatches=5&maxBytes=20971520&groupBy=job
did not see panics like
Aug 25 12:02:04.870: INFO: "[sig-instrumentation] Prometheus metrics should be available after an upgrade": panic: Your test failed. Ginkgo panics to prevent subsequent assertions from running. Normally Ginkgo rescues this panic so you shouldn't see it. But, if you make an assertion in a goroutine, Ginkgo can't capture the panic. To circumvent this, you should call defer GinkgoRecover() at the top of the goroutine that caused this panic.
in https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/periodic-ci-openshift-release-master-ci-4.11-e2e-azure-ovn-upgrade/1695032932801974272, we can close this bug, but found another bug OCPBUGS-20208
Junqi Zhao
added a comment - searched upgrade to 4.15 tests
https://search.ci.openshift.org/?search=Prometheus+metrics+should+be+available+after+an+upgrade&maxAge=168h&context=1&type=bug%2Bjunit&name=4.15.*-upgrade.*&excludeName=&maxMatches=5&maxBytes=20971520&groupBy=job
did not see panics like
Aug 25 12:02:04.870: INFO: "[sig-instrumentation] Prometheus metrics should be available after an upgrade" : panic:
Your test failed.
Ginkgo panics to prevent subsequent assertions from running.
Normally Ginkgo rescues this panic so you shouldn't see it.
But, if you make an assertion in a goroutine, Ginkgo can't capture the panic.
To circumvent this , you should call
defer GinkgoRecover()
at the top of the goroutine that caused this panic.
in https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/periodic-ci-openshift-release-master-ci-4.11-e2e-azure-ovn-upgrade/1695032932801974272, we can close this bug, but found another bug OCPBUGS-20208 
Andy Goldstein (Inactive)
added a comment - cc bbennett@redhat.com in case this is networking related
Andy Goldstein (Inactive)
added a comment - cc bbennett@redhat.com in case this is networking related Andy Goldstein (Inactive)
added a comment - Andy Goldstein (Inactive)
added a comment - As seen in https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/periodic-ci-openshift-release-master-ci-4.11-e2e-azure-ovn-upgrade/1695032932801974272 
Since the problem described in this issue should be resolved in a recent advisory, it has been closed.
For information on the advisory (Critical: OpenShift Container Platform 4.15.0 bug fix and security update), and where to find the updated files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2023:7198