OCPBUGS-106190: Make oc rsh test resilient - #31515
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: automatic mode |
|
@ardaguclu: This pull request explicitly references no 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 openshift-eng/jira-lifecycle-plugin repository. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
WalkthroughThe Changesoc rsh command execution
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This PR only makes the oc rsh test more resilient to expected WebSocket behavior; no actionable merge-blocking risk remains after normal verification checks. 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
/test e2e-gcp-ovn-rhcos9-techpreview |
|
/test e2e-gcp-ovn-techpreview |
|
Scheduling required tests: |
|
/retitle OCPBUGS-106190: Make oc rsh test resilient |
|
@ardaguclu: This pull request references Jira Issue OCPBUGS-106190, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
The bug has been updated to refer to the pull request using the external bug tracker. 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 openshift-eng/jira-lifecycle-plugin repository. |
|
/retest |
3 similar comments
|
/retest |
|
/retest |
|
/retest |
|
@ardaguclu Thank you for taking on the fix for this!! In your mind, will this be a concern in the real world? Will a certain percentage of short rsh commands from users fail and cause confusion? |
This is tracked in upstream kubernetes/kubernetes#140102. Feature gate is still in Beta. I think, this won't be a production issue. |
This rarely occurs, only when Close signal is missed under excessive CPU load. |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ardaguclu, oceanc80, xueqzhan The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
|
/retest |
|
@ardaguclu: The following tests failed, say
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-sigs/prow repository. I understand the commands that are listed here. |
|
Risk analysis has seen new tests most likely introduced by this PR. New Test Risks for sha: e775c9d
New tests seen in this PR at sha: e775c9d
|
When
ExtendWebSocketsToKubeletis enabled (Beta in 1.36), WebSocket exec/attach connections are proxied through the API server's UpgradeAwareHandler to the kubelet. The proxy tears down both connections as soon as one direction's io.Copy completes. For fast-completing commands (e.g., mkdir), the kubelet's WebSocket close frame can be lost.This PR updates the test to make it more resilient to the new behavior.
Summary by CodeRabbit