New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug 1833387: test/extended/operators/operators: Don't worry about Progressing ClusterOperator #24992
Bug 1833387: test/extended/operators/operators: Don't worry about Progressing ClusterOperator #24992
Conversation
…terOperator We've been failing this test on Progressing=True since 6300a87 (e2e: Test that all operators are stable, 2019-02-15, openshift#22058). But the installer only cares about ClusterVersion Available=True [1], which means some operators who have leveled (as far as the cluster-version operator is concerned) may still have Progressing=True when the installer declares success. We aren't too concerned about that as long as operators are available and not degraded, so stop worrying about it in this test. This avoids failures like [2]: [sig-arch][Early] Managed cluster should start all core operators [Suite:openshift/conformance/parallel] fail [github.com/openshift/origin/test/extended/operators/operators.go:159]: May 8 13:27:58.992: Some cluster operators never became ready: kube-apiserver (Progressing=True NodeInstaller: NodeInstallerProgressing: 1 nodes are at revision 5; 2 nodes are at revision 7) although such failures rarely killed the job, because the cluster was happy enough by the time the "start all core operators" test was rerun to detect "flakes" at the end of the suite. [1]: https://github.com/openshift/installer/blob/aecb9201459e3e92f12344e78aaaf03b6550fde7/cmd/openshift-install/create.go#L382-L384 [2]: https://deck-ci.apps.ci.l2s4.p1.openshiftapps.com/view/gcs/origin-ci-test/logs/release-openshift-ocp-installer-e2e-gcp-4.5/1040
@wking: This pull request references Bugzilla bug 1833387, which is valid. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/assign @smarterclayton |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: smarterclayton, wking The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
/retest Please review the full test history for this PR and help us cut down flakes. |
@wking: Some pull requests linked via external trackers have merged: openshift/origin#24992. The following pull requests linked via external trackers have not merged:
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
We've been failing this test on
Progressing=True
since 6300a87 (#22058). But the installer only cares aboutClusterVersion
Available=True
, which means some operators who have leveled (as far as the cluster-version operator is concerned) may still haveProgressing=True
when the installer declares success. We aren't too concerned about that as long as operators are available and not degraded, so stop worrying about it in this test. This avoids failures like:although such failures rarely killed the job, because the cluster was happy enough by the time the "start all core operators" test was rerun to detect "flakes" at the end of the suite.