HOSTEDCP-966: require hypershift e2e for operators in control plane#39641
HOSTEDCP-966: require hypershift e2e for operators in control plane#39641sjenning wants to merge 1 commit intoopenshift:masterfrom
Conversation
|
@sjenning: This pull request references HOSTEDCP-966 which is a valid jira issue. DetailsIn 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. |
|
[REHEARSALNOTIFIER]
Prior to this PR being merged, you will need to either run and acknowledge or opt to skip these rehearsals. Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
@sjenning: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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. I understand the commands that are listed here. |
|
@sjenning: This pull request references HOSTEDCP-966 which is a valid jira issue. DetailsIn 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. |
|
/lgtm |
|
I think it makes sense from an MCO perspective, the main concern being how stable this would be. Looking at the recent runs: https://prow.ci.openshift.org/job-history/gs/origin-ci-test/pr-logs/directory/pull-ci-openshift-machine-config-operator-master-e2e-hypershift Seems about 50/50? I guess we can retest until passing, but it may be hard to determine whether a test failure is due to a flake (looks like it would happen a lot atm) vs actually failing. Is the MCO tests reflective of the general pass rate? Or are we an outlier? Would there be plans to get the e2e test to say, 80% or 90% success rate? Then I think we would be a bit more confident in the signal and having it required Alternatively, I am also fine with merging this, but I am concerned we will flake a lot and end up having to override if it becomes more noisy/brittle, which would defeat the purpose of making it required. Would the Hypershift team own and help us debug this test? |
|
The hypershift job in cluster-storage-operator succeeded only once in past 3 months. IMO that does not qualify it to be blocking. |
|
Agree with Jerry's assessment. Considering limited knowledge of e2e-hypershift test, i am curious to know which team is responsible to troubleshoot the future failure of this test? |
|
The hypershift team + TRT. It is a release blocking job so if it breaks, we'll know almost immediately and it will be high priority to fix it. Note Making this required really just provides pre-merge protection for your teams so that you don't break at the release level. |
|
This really helps, thanks for the additional context Seth! |
yuqi-zhang
left a comment
There was a problem hiding this comment.
approving from the MCO context, should be good to go, thanks Seth!
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: enxebre, sjenning, yuqi-zhang The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
I'm updating the actual e2e job used in storage tests + make it blocking in #39783 |
|
close in favor of #39854 |
Hypershift e2e is now blocking on ci release stream.
We should block breaking changes from merging for operators/components running in the Hypershift control plane.