Skip to content

OCPBUGS-100065: UPSTREAM: <carry>: require all aggregated apiserver endpoints reachable in readyz check - #2730

Open
mkowalski wants to merge 1 commit into
openshift:masterfrom
mkowalski:ocpbugs-100065-aggregated-readyz-all-endpoints
Open

OCPBUGS-100065: UPSTREAM: <carry>: require all aggregated apiserver endpoints reachable in readyz check#2730
mkowalski wants to merge 1 commit into
openshift:masterfrom
mkowalski:ocpbugs-100065-aggregated-readyz-all-endpoints

Conversation

@mkowalski

@mkowalski mkowalski commented Jul 28, 2026

Copy link
Copy Markdown

Summary

Fixes OCPBUGS-100065: 10-15s of oauth-api-new-connections / openshift-api-new-connections disruption during metal-ipi upgrades (~30-50% of master-updating runs).

  • The api-openshift-apiserver-available / api-openshift-oauth-apiserver-available readyz checks (sdn_readyz_wait.go) latched complete on the first successful connection to any single endpoint of the aggregated apiserver service. On a freshly rebooted master, kube-apiserver starts while OVN is still converging; connectivity flaps, and a lucky one-off connection marks the instance ready (observed: reached openshift-oauth-apiserver via SDN after 13067 milliseconds at 08:30:33 while the availability controller logged context deadline exceeded to another endpoint 3s earlier — run 2081616371841503232).
  • The external LB (haproxy on metal) follows /readyz and routes ~1/3 of new connections to the instance; aggregator requests ride http2 connections established during the blackhole window and fail with 503 error trying to reach service: http2: client connection lost + header timeouts for 40-70s until the transport declares the connections dead. Reproduced with identical signature in run 2080091718912315392; 10/10 analyzed runs with >=10s disruption show an episode starting 39-74s after a master Rebooted event.
  • Fix: require every listed ready endpoint to be reachable on 3 consecutive polls before the check reports complete. This both delays readiness until the pod network actually converged and ensures backend connections are established post-convergence (no dead-conn pinning). Escape hatches unchanged: missing endpoints object completes immediately; the 60s overall timeout still reports ready no matter what to avoid the rebootstrapping deadlock.
  • Adds unit tests for the new allEndpointsReachable helper.

Test plan

  • gofmt, go vet, go build ./openshift-kube-apiserver/...
  • go test ./openshift-kube-apiserver/openshiftkubeapiserver/ (new + existing tests pass)
  • e2e-metal-ipi upgrade jobs: verify oauth-api-new-connections disruption episodes no longer correlate with master reboots (expect P50 back to ~0-4s)

This PR was generated using AI. Please verify before acting on it.

Summary by CodeRabbit

  • Bug Fixes

    • Improved SDN readiness checks to verify that all aggregated API endpoints are reachable.
    • Readiness now requires successful connectivity across multiple consecutive polling cycles, resetting after failures.
    • HTTP responses are treated as reachable regardless of status code.
    • Services with no available endpoint addresses are correctly reported as not ready.
  • Tests

    • Added coverage for multiple endpoints, unavailable endpoints, empty endpoint lists, and varied HTTP responses.

…le in readyz check

The api-openshift-apiserver-available and api-openshift-oauth-apiserver-available
readyz checks previously latched complete on the first successful connection to
any single endpoint of the aggregated apiserver service.  On a freshly rebooted
master the pod network may still be converging (OVN flow/route programming) when
kube-apiserver starts, so a lucky one-off connection could mark the apiserver
ready while connectivity to the remaining endpoints was still broken.  Once the
external load balancer follows readyz and routes traffic to this instance, its
aggregator proxies requests over connections established during the blackhole
window, and the pinned http2 connections produce 503 'error trying to reach
service: http2: client connection lost' plus header timeouts for tens of
seconds - observed as 10-15s of oauth-api/openshift-api new-connection
disruption on metal-ipi upgrade jobs (~30-50% of master-updating runs).

Require every listed ready endpoint address to be reachable on three
consecutive polls before reporting the check complete.  The existing escape
hatches are unchanged: missing endpoints object still completes immediately,
and the 60 second overall timeout still reports ready no matter what to avoid
a rebootstrapping deadlock.

Add unit tests for the new allEndpointsReachable helper.

Assisted-By: Claude Fable 5
@openshift-ci-robot openshift-ci-robot added backports/unvalidated-commits Indicates that not all commits come to merged upstream PRs. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Jul 28, 2026
@openshift-ci-robot

Copy link
Copy Markdown

@mkowalski: This pull request references Jira Issue OCPBUGS-100065, which is invalid:

  • expected the bug to target the "5.0.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

Summary

Fixes OCPBUGS-100065: 10-15s of oauth-api-new-connections / openshift-api-new-connections disruption during metal-ipi upgrades (~30-50% of master-updating runs).

  • The api-openshift-apiserver-available / api-openshift-oauth-apiserver-available readyz checks (sdn_readyz_wait.go) latched complete on the first successful connection to any single endpoint of the aggregated apiserver service. On a freshly rebooted master, kube-apiserver starts while OVN is still converging; connectivity flaps, and a lucky one-off connection marks the instance ready (observed: reached openshift-oauth-apiserver via SDN after 13067 milliseconds at 08:30:33 while the availability controller logged context deadline exceeded to another endpoint 3s earlier — run 2081616371841503232).
  • The external LB (haproxy on metal) follows /readyz and routes ~1/3 of new connections to the instance; aggregator requests ride http2 connections established during the blackhole window and fail with 503 error trying to reach service: http2: client connection lost + header timeouts for 40-70s until the transport declares the connections dead. Reproduced with identical signature in run 2080091718912315392; 10/10 analyzed runs with >=10s disruption show an episode starting 39-74s after a master Rebooted event.
  • Fix: require every listed ready endpoint to be reachable on 3 consecutive polls before the check reports complete. This both delays readiness until the pod network actually converged and ensures backend connections are established post-convergence (no dead-conn pinning). Escape hatches unchanged: missing endpoints object completes immediately; the 60s overall timeout still reports ready no matter what to avoid the rebootstrapping deadlock.
  • Adds unit tests for the new allEndpointsReachable helper.

Test plan

  • gofmt, go vet, go build ./openshift-kube-apiserver/...
  • go test ./openshift-kube-apiserver/openshiftkubeapiserver/ (new + existing tests pass)
  • e2e-metal-ipi upgrade jobs: verify oauth-api-new-connections disruption episodes no longer correlate with master reboots (expect P50 back to ~0-4s)

This PR was generated using AI. Please verify before acting on it.

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.

@openshift-ci-robot

Copy link
Copy Markdown

@mkowalski: the contents of this pull request could not be automatically validated.

The following commits could not be validated and must be approved by a top-level approver:

Comment /validate-backports to re-evaluate validity of the upstream PRs, for example when they are merged upstream.

@coderabbitai

coderabbitai Bot commented Jul 28, 2026

Copy link
Copy Markdown

Walkthrough

The SDN aggregated API readiness check now probes all endpoint addresses and requires multiple consecutive successful polls. Tests cover endpoint reachability, arbitrary HTTP responses, failed endpoints, and empty endpoint lists.

Changes

SDN readiness validation

Layer / File(s) Summary
Endpoint reachability probing
openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait.go, openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait_test.go
Adds allEndpointsReachable to probe every endpoint address and adds tests for reachable, failing, empty, and non-200 HTTP responses.
Consecutive readiness polling
openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait.go
Tracks consecutive successful all-endpoint checks, resets the count after failures, and reports readiness after the configured threshold.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant ReadinessPollLoop
  participant allEndpointsReachable
  participant AggregatedAPIEndpoint
  loop Each poll
    ReadinessPollLoop->>allEndpointsReachable: Check all endpoint addresses
    allEndpointsReachable->>AggregatedAPIEndpoint: HTTPS GET on port 8443
    AggregatedAPIEndpoint-->>allEndpointsReachable: HTTP response or connection failure
    allEndpointsReachable-->>ReadinessPollLoop: All reachable or failure
  end
  ReadinessPollLoop-->>ReadinessPollLoop: Reset or increment consecutive successes
  ReadinessPollLoop-->>ReadinessPollLoop: Signal readiness after threshold
Loading
🚥 Pre-merge checks | ✅ 15
✅ Passed checks (15 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly matches the main change: requiring all aggregated apiserver endpoints to be reachable in the readyz check.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names ✅ Passed No Ginkgo titles were added; the new tests use static Go function names only, with no dynamic values or unstable identifiers.
Test Structure And Quality ✅ Passed New tests are small, single-purpose unit tests (not Ginkgo), use deferred cleanup and 1s timeouts, and match existing package style.
Microshift Test Compatibility ✅ Passed No new Ginkgo e2e tests were added; the new tests are plain Go unit tests using only corev1 Endpoints and httptest, with no MicroShift-unsupported APIs.
Single Node Openshift (Sno) Test Compatibility ✅ Passed Only standard Go unit tests were added; no Ginkgo e2e tests or SNO-specific multi-node assumptions appear in the touched files.
Topology-Aware Scheduling Compatibility ✅ Passed The PR only changes readiness polling in sdn_readyz_wait.go and adds unit tests; no manifests, replicas, node selectors, affinity, or topology-aware scheduling code.
Ote Binary Stdout Contract ✅ Passed PASS: The changed files add no main/init/TestMain/suite setup, and the only klog calls are inside normal runtime methods, not process-level startup code.
Ipv6 And Disconnected Network Test Compatibility ✅ Passed PASS: The added tests are plain unit tests, not Ginkgo e2e, and use httptest/local loopback; production code uses net.JoinHostPort for IPv6-safe host formatting.
No-Weak-Crypto ✅ Passed Touched files add only standard TLS test helpers and endpoint reachability logic; no weak algorithms, custom crypto, or secret comparisons were introduced.
Container-Privileges ✅ Passed PR only modifies Go source/tests; no container/K8s manifests or privilege settings were added.
No-Sensitive-Data-In-Logs ✅ Passed No new sensitive logging added; the patch only changes readiness logic and a generic success message, while existing debug endpoint-response logs were unchanged.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands.

@openshift-ci-robot

Copy link
Copy Markdown

@mkowalski: This pull request references Jira Issue OCPBUGS-100065, which is invalid:

  • expected the bug to target the "5.0.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

Details

In response to this:

Summary

Fixes OCPBUGS-100065: 10-15s of oauth-api-new-connections / openshift-api-new-connections disruption during metal-ipi upgrades (~30-50% of master-updating runs).

  • The api-openshift-apiserver-available / api-openshift-oauth-apiserver-available readyz checks (sdn_readyz_wait.go) latched complete on the first successful connection to any single endpoint of the aggregated apiserver service. On a freshly rebooted master, kube-apiserver starts while OVN is still converging; connectivity flaps, and a lucky one-off connection marks the instance ready (observed: reached openshift-oauth-apiserver via SDN after 13067 milliseconds at 08:30:33 while the availability controller logged context deadline exceeded to another endpoint 3s earlier — run 2081616371841503232).
  • The external LB (haproxy on metal) follows /readyz and routes ~1/3 of new connections to the instance; aggregator requests ride http2 connections established during the blackhole window and fail with 503 error trying to reach service: http2: client connection lost + header timeouts for 40-70s until the transport declares the connections dead. Reproduced with identical signature in run 2080091718912315392; 10/10 analyzed runs with >=10s disruption show an episode starting 39-74s after a master Rebooted event.
  • Fix: require every listed ready endpoint to be reachable on 3 consecutive polls before the check reports complete. This both delays readiness until the pod network actually converged and ensures backend connections are established post-convergence (no dead-conn pinning). Escape hatches unchanged: missing endpoints object completes immediately; the 60s overall timeout still reports ready no matter what to avoid the rebootstrapping deadlock.
  • Adds unit tests for the new allEndpointsReachable helper.

Test plan

  • gofmt, go vet, go build ./openshift-kube-apiserver/...
  • go test ./openshift-kube-apiserver/openshiftkubeapiserver/ (new + existing tests pass)
  • e2e-metal-ipi upgrade jobs: verify oauth-api-new-connections disruption episodes no longer correlate with master reboots (expect P50 back to ~0-4s)

This PR was generated using AI. Please verify before acting on it.

Summary by CodeRabbit

  • Bug Fixes

  • Improved SDN readiness checks to verify that all aggregated API endpoints are reachable.

  • Readiness now requires successful connectivity across multiple consecutive polling cycles, resetting after failures.

  • HTTP responses are treated as reachable regardless of status code.

  • Services with no available endpoint addresses are correctly reported as not ready.

  • Tests

  • Added coverage for multiple endpoints, unavailable endpoints, empty endpoint lists, and varied HTTP responses.

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.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait.go (1)

152-159: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Do not follow redirects in the readiness probe. http.Client will chase 3xx responses, so a healthy endpoint that redirects to an unavailable target is treated as down and resets the readiness streak. Set CheckRedirect to return http.ErrUseLastResponse and add a 302 regression test.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait.go` around
lines 152 - 159, Update the http.Client construction in the readiness probe to
set CheckRedirect so redirects return http.ErrUseLastResponse instead of being
followed. Add a regression test covering a 302 response and verify the probe
treats the original endpoint as healthy without contacting the redirected
target.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait_test.go`:
- Around line 61-62: Update the test setup around url.Parse, net.SplitHostPort,
and the server cleanup to handle each returned error explicitly. Fail the test
immediately with useful context when URL parsing or host/port splitting fails,
and ensure server.Close errors are checked and reported so cleanup failures
cannot be ignored.

In `@openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait.go`:
- Around line 46-48: Update the response handling near the readiness probe to
stop calling httputil.DumpResponse with body dumping; log resp.Status directly
in the existing klog.V(4) message, and check and handle any error returned by
resp.Body.Close().

---

Outside diff comments:
In `@openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait.go`:
- Around line 152-159: Update the http.Client construction in the readiness
probe to set CheckRedirect so redirects return http.ErrUseLastResponse instead
of being followed. Add a regression test covering a 302 response and verify the
probe treats the original endpoint as healthy without contacting the redirected
target.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 1fc8d5ef-ba01-47d5-bb2b-a9c4b62f90c4

📥 Commits

Reviewing files that changed from the base of the PR and between 63ee93d and 8f37f3b.

📒 Files selected for processing (2)
  • openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait.go
  • openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait_test.go

Comment on lines +61 to +62
u, _ := url.Parse(server.URL)
host, port, _ := net.SplitHostPort(u.Host)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail
rg -n -C 2 'url\.Parse\(server\.URL\)|net\.SplitHostPort\(u\.Host\)|listener\.Close\(\)' \
  openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait_test.go

Repository: openshift/kubernetes

Length of output: 819


🏁 Script executed:

#!/bin/bash
set -euo pipefail
sed -n '1,140p' openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait_test.go | cat -n

Repository: openshift/kubernetes

Length of output: 4103


Handle the ignored URL, host/port, and Close errors here. Dropping these return values can turn a setup/cleanup failure into a misleading test result or leave the listener open.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait_test.go`
around lines 61 - 62, Update the test setup around url.Parse, net.SplitHostPort,
and the server cleanup to handle each returned error explicitly. Fail the test
immediately with useful context when URL parsing or host/port splitting fails,
and ensure server.Close errors are checked and reported so cleanup failures
cannot be ignored.

Source: Path instructions

Comment on lines +46 to +48
response, dumpErr := httputil.DumpResponse(resp, true)
klog.V(4).Infof("reached to connect to %q: %v\n%v", url, dumpErr, string(response))
resp.Body.Close()

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail
rg -n -C 3 'DumpResponse|resp\.Body\.Close|connected to' \
  openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait.go

Repository: openshift/kubernetes

Length of output: 466


🏁 Script executed:

#!/bin/bash
set -euo pipefail

FILE="openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait.go"
wc -l "$FILE"
sed -n '1,140p' "$FILE"

Repository: openshift/kubernetes

Length of output: 6164


Avoid dumping the full response body here. DumpResponse(resp, true) still drains and allocates the entire body before the V(4) log call, so a slow or large response can delay readiness probes unnecessarily. Log resp.Status instead and handle resp.Body.Close() errors.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@openshift-kube-apiserver/openshiftkubeapiserver/sdn_readyz_wait.go` around
lines 46 - 48, Update the response handling near the readiness probe to stop
calling httputil.DumpResponse with body dumping; log resp.Status directly in the
existing klog.V(4) message, and check and handle any error returned by
resp.Body.Close().

Source: Path instructions

@openshift-ci
openshift-ci Bot requested review from jerpeter1 and jubittajohn July 28, 2026 15:16
@openshift-ci

openshift-ci Bot commented Jul 28, 2026

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mkowalski
Once this PR has been reviewed and has the lgtm label, please assign p0lyn0mial for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@mkowalski

Copy link
Copy Markdown
Author

/payload-job periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ipi-upgrade-ovn-ipv6
/payload-job periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ipi-ovn-upgrade-runc

@openshift-ci

openshift-ci Bot commented Jul 28, 2026

Copy link
Copy Markdown

@mkowalski: trigger 2 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

  • periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ipi-upgrade-ovn-ipv6
  • periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ipi-ovn-upgrade-runc

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/18ec7f00-8ab2-11f1-8658-12de802f0584-0

@mkowalski

Copy link
Copy Markdown
Author

/payload-job periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ipi-upgrade-ovn-ipv6
/payload-job periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ipi-ovn-upgrade-runc

@openshift-ci

openshift-ci Bot commented Jul 28, 2026

Copy link
Copy Markdown

@mkowalski: trigger 2 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

  • periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ipi-upgrade-ovn-ipv6
  • periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ipi-ovn-upgrade-runc

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/51fefa00-8abe-11f1-92e8-b43b13b56af5-0

@mkowalski

Copy link
Copy Markdown
Author

Payload test results (2 rounds, 3 of 4 runs complete, all rebooted 3/3 masters = valid trials for OCPBUGS-100065):

Run Result oauth-api-new-connections disruption
R1 ipv6 SUCCESS 2s
R1 runc FAILURE* 0s
R2 runc FAILURE* 1s
R2 ipv6 still running -

* both runc failures are [sig-ci][Early] prow job name should match os version — a payload-job naming artifact, unrelated to this change (R2 also flaked CVO acknowledges upgrade).

Baseline for comparison: ~30-50% of master-updating runs showed 10-15s disruption with episodes starting 39-74s after a master reboot.

New code path confirmed active on all masters: reached all openshift-oauth-apiserver endpoints via SDN after 8200-25056 milliseconds — the check now genuinely waits out OVN convergence (previously latched on a single lucky connect, e.g. 13s mid-flap). One residual 1-2s blip remains (single ReverseProxy http2: client connection lost on one master at 22:27:05, from connections established by in-process clients before readiness) — matches the known residual gap; candidate follow-up is h2 ping-based dead-conn detection on aggregator transports.

3 clean trials is suggestive but not conclusive for a ~30-50% stochastic race — will run /payload-aggregate for statistical confidence before merge.


This comment was generated using AI. Please verify before acting on it.

@mkowalski

Copy link
Copy Markdown
Author

/payload-aggregate periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ipi-upgrade-ovn-ipv6 10

@openshift-ci

openshift-ci Bot commented Jul 29, 2026

Copy link
Copy Markdown

@mkowalski: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

  • periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ipi-upgrade-ovn-ipv6

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/7d56f560-8ae9-11f1-9107-2e8ae1456132-0

@mkowalski

Copy link
Copy Markdown
Author

Aggregate results (10 runs + 1 earlier, all valid master-updating trials):

oauth-api-new-connections totals: 0, 0, 0, 0, 0, 1, 1, 2, 3, 5, 12 seconds — vs baseline where ~31-50% of runs hit 10-15s.

The readiness gate works as designed: in the one 12s outlier (run 2082271087302807552) the check correctly held readiness back through 20+ failed probes (dial tcp ... network is unreachable) and completed after 3 consecutive clean passes at +22s — but pod-network connectivity regressed again ~55s after readiness (coinciding with the next master's drain), reproducing the timeout -> http2: client connection lost tail. A readiness gate cannot protect connections that break after readiness.

Net: median disruption drops from ~5-10s to ~1s, >=10s incidence from ~31-50% to 1/11. The residual case confirms the complementary fix (h2 ping-based dead-connection detection on aggregator transports, OCPBUGS-100065 suggestion #2) is required to reach a strict zero. This PR stands on its own as a substantial reduction and is the correct-by-construction half of the fix.


This comment was generated using AI. Please verify before acting on it.

@openshift-ci

openshift-ci Bot commented Jul 29, 2026

Copy link
Copy Markdown

@mkowalski: This PR was included in a payload test run from #2732
trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

  • periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ipi-upgrade-ovn-ipv6

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/5f31a690-8b50-11f1-893d-e74f5bc1047d-0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backports/unvalidated-commits Indicates that not all commits come to merged upstream PRs. jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants