We see the Kube API to be unavailable during upgrades on different platforms. This is not supposed to happen if graceful termination and LB endpoint reconcialation by the cloud provider work correctly. Note: openshift-apiserver APIs are unavailable to if the kube-apiserver is not serving correctly. This is a top-level umbrella bug. Never clone this into releases!
*** Bug 1828861 has been marked as a duplicate of this bug. ***
Work in progress.
Saving folks some click-throughs, current blockers are: * Bug 1845410: GCP (4.6) * Bug 1845412: AWS (4.6) * Bug 1845414: Azure (4.6) * Bug 1845416: GCP (4.5)
*** Bug 1852601 has been marked as a duplicate of this bug. ***
WIP.
Mentioning affected test-cases for Sippy: Kubernetes APIs remain available OpenShift APIs remain available Possibly also: OAuth APIs remain available
And with the sigs, in case that matters to Sippy: [sig-api-machinery] Kubernetes APIs remain available [sig-api-machinery] OpenShift APIs remain available [sig-api-machinery] OAuth APIs remain available
*** Bug 1867237 has been marked as a duplicate of this bug. ***
This is an umbrella bug for API disruption. Labelling with UpcomingSprint.
This bug hasn't had any activity in the last 30 days. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're marking this bug as "LifecycleStale" and decreasing the severity/priority. If you have further information on the current state of the bug, please update it, otherwise this bug can be closed in about 7 days. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. Additionally, you can add LifecycleFrozen into Keywords if you think this bug should never be marked as stale. Please consult with bug assignee before you do that.
*** Bug 1883207 has been marked as a duplicate of this bug. ***
The LifecycleStale keyword was removed because the bug got commented on recently. The bug assignee was notified.
Lots of "operator install *" tests, mostly in 4.7, are also failing with "operator is not reporting conditions".
My impression was that this umbrella bug would remain open until all child bugs were resolved. Bug 1845410 and others are still open at the moment.
Setting blocker- as priority = low.
As build watcher, I noticed that "[sig-api-machinery] OpenShift APIs remain available" (which is in this BZ's environment field) is failing in the "release-openshift-origin-installer-old-rhcos-e2e-aws-4.7" job 50% of the time.
The failures in release-openshift-origin-installer-old-rhcos-e2e-aws-4.7 all fail with errors like the following: API "openshift-api-available" was unreachable during disruption for at least 1m20s of 47m35s (3%), this is currently sufficient to pass the test/job but not considered completely correct: Failing and logging "this is currently sufficient" seems contradictory; perhaps the pass/fail logic just needs to be fixed, at least for these particular failures, to pass if the threshold is not exceeded.
Miciah, example old-RHCOS 4.7 job [1] has: API "openshift-api-available" was unreachable during disruption for at least 1m17s of 44m44s (3%), this is currently sufficient to pass the test/job but not considered completely correct: But it's not failing the test. That test-case gets that^ one failure round, and then a subsequent no-op "pass" round, so JUnit consumers count it under the "flaky" set, not the "failing" set. Not an awesome UX, but the best we can do today. [1]: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/release-openshift-origin-installer-old-rhcos-e2e-aws-4.7/1362497177733042176
Looks like some very stale dependent bugs attached to this. Removing trt tracking for this issue.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days