Skip to content

OCPBUGS-98461: requeue CRR on transiently unavailable resources - #8997

Merged
openshift-merge-bot[bot] merged 1 commit into
openshift:mainfrom
jparrill:OCPBUGS-98461
Jul 16, 2026
Merged

OCPBUGS-98461: requeue CRR on transiently unavailable resources#8997
openshift-merge-bot[bot] merged 1 commit into
openshift:mainfrom
jparrill:OCPBUGS-98461

Conversation

@jparrill

@jparrill jparrill commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Change requeueSoon from false to true in 6 return paths across ensureOldSignerCertificateRevoked and ensureNewSignerCertificatePropagated where a resource is transiently nil

Fixes

Root Cause

CertificateRevocationRequest operations stall at PreviousCertificatesRevoked=False for 10+ minutes (3/8 runs, Jul 8-10, most frequent CI failure). #8563 fixed one instance of this class of bug (stale trust bundle cache returning requeueSoon=false), but three other return paths in each function have the same issue:

Line Condition Before After
:690, :1011 secretForSignerClass not found requeueSoon=false requeueSoon=true
:698, :1018 signer secret nil requeueSoon=false requeueSoon=true
:717, :1029 trust bundle ConfigMap nil requeueSoon=false requeueSoon=true

When any of these resources is transiently unavailable (being re-created, not yet propagated), the controller returned needsWork=true, requeueSoon=false — waiting for a watch event that might never come. With requeueSoon=true, it retries on the next synthetic requeue.

Frequency

3/8 runs in Jul 8-10 window. Most frequent issue in e2e-aws-ovn. One CRR completed in 2min while a parallel one in the same run stalled for 10min+ — consistent with a transient resource availability race.

Test plan

  • Unit test: "When trust bundle ConfigMap is transiently unavailable during revocation it should requeue"
  • go test ./control-plane-pki-operator/certificaterevocationcontroller/ — all pass
  • make lint — 0 issues
  • make verify — clean (except expected uncommitted files)

/cc @csrwng

🤖 Generated with Claude Code

Summary by CodeRabbit

Summary by CodeRabbit

  • Bug Fixes

    • Updated certificate revocation reconciliation to automatically retry when signer certificate secrets or aggregated trust-bundle data aren’t available yet.
    • Ensures reconciliation requeues (instead of prematurely completing) while prerequisites are still being propagated.
  • Tests

    • Added additional coverage for scenarios where the trust-bundle ConfigMap is temporarily missing, validating that the controller requeues without errors.

@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

@openshift-ci
openshift-ci Bot requested a review from csrwng July 14, 2026 11:07
@openshift-ci

openshift-ci Bot commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

@jparrill: GitHub didn't allow me to request PR reviews from the following users: cewong.

Note that only openshift members and repo collaborators can review this PR, and authors cannot review their own PRs.

Details

In response to this:

Summary

  • Change requeueSoon from false to true in 6 return paths across ensureOldSignerCertificateRevoked and ensureNewSignerCertificatePropagated where a resource is transiently nil

Fixes

Root Cause

CertificateRevocationRequest operations stall at PreviousCertificatesRevoked=False for 10+ minutes (3/8 runs, Jul 8-10, most frequent CI failure). #8563 fixed one instance of this class of bug (stale trust bundle cache returning requeueSoon=false), but three other return paths in each function have the same issue:

Line Condition Before After
:690, :1011 secretForSignerClass not found requeueSoon=false requeueSoon=true
:698, :1018 signer secret nil requeueSoon=false requeueSoon=true
:717, :1029 trust bundle ConfigMap nil requeueSoon=false requeueSoon=true

When any of these resources is transiently unavailable (being re-created, not yet propagated), the controller returned needsWork=true, requeueSoon=false — waiting for a watch event that might never come. With requeueSoon=true, it retries on the next synthetic requeue.

Frequency

3/8 runs in Jul 8-10 window. Most frequent issue in e2e-aws-ovn. One CRR completed in 2min while a parallel one in the same run stalled for 10min+ — consistent with a transient resource availability race.

Test plan

  • Unit test: "When trust bundle ConfigMap is transiently unavailable during revocation it should requeue"
  • go test ./control-plane-pki-operator/certificaterevocationcontroller/ — all pass
  • make lint — 0 issues
  • make verify — clean (except expected uncommitted files)

/cc @csrwng @CEWong

🤖 Generated with Claude Code

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-sigs/prow repository.

@coderabbitai

coderabbitai Bot commented Jul 14, 2026

Copy link
Copy Markdown
Contributor
📝 Walkthrough

Walkthrough

The certificate revocation controller now returns requeue=true when signer certificate data or aggregated trust-bundle ConfigMaps are unavailable during propagation and revocation checks. Existing completion and error behavior remains unchanged. Tests cover missing signer secrets and trust-bundle ConfigMaps, verifying reconciliation requeues without errors.

Suggested reviewers: csrwng, sdminonne

🚥 Pre-merge checks | ✅ 11
✅ Passed checks (11 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: CRRs now requeue when dependent resources are transiently unavailable.
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 PASS: All added test titles are static literal strings; no formatted or data-derived Ginkgo/t.Run names were introduced.
Test Structure And Quality ✅ Passed Tests are isolated subtests over in-memory fakes, use no cluster resources or waits, and match existing patterns; no structure/quality issues found.
Topology-Aware Scheduling Compatibility ✅ Passed Only requeue logic and unit tests changed; no node selectors, affinity, spread, PDB, or topology-dependent scheduling constraints were added.
Ipv6 And Disconnected Network Test Compatibility ✅ Passed Only unit tests (t.Run) were added; no new Ginkgo e2e tests or public-network/IPv4 assumptions appear in the diff.
No-Weak-Crypto ✅ Passed Only SHA-224/SHA-256 and x509/test PKI helpers are used; no MD5/SHA1/DES/RC4/ECB, custom crypto, or unsafe secret comparisons found.
Container-Privileges ✅ Passed PASS: The PR only changes Go controller/test code; no container/K8s manifests or privilege settings (privileged, hostPID/Network/IPC, CAP_SYS_ADMIN, allowPrivilegeEscalation) were added.
No-Sensitive-Data-In-Logs ✅ Passed No new logging was added or changed; the patch only flips requeue flags and adds tests. Inspected klog usage is generic and doesn’t log secrets or PII.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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

@openshift-ci openshift-ci Bot added area/control-plane-pki-operator Indicates the PR includes changes for the control plane PKI operator - in an OCP release approved Indicates a PR has been approved by an approver from all required OWNERS files. and removed do-not-merge/needs-area labels Jul 14, 2026
@jparrill jparrill changed the title fix(OCPBUGS-98461): requeue CRR on transiently unavailable resources OCPBUGS-98461: requeue CRR on transiently unavailable resources Jul 14, 2026
@openshift-ci-robot openshift-ci-robot added jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. labels Jul 14, 2026
@openshift-ci-robot

Copy link
Copy Markdown

@jparrill: This pull request references Jira Issue OCPBUGS-98461, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target version (5.0.0) matches configured target version for branch (5.0.0)
  • bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

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

Details

In response to this:

Summary

  • Change requeueSoon from false to true in 6 return paths across ensureOldSignerCertificateRevoked and ensureNewSignerCertificatePropagated where a resource is transiently nil

Fixes

Root Cause

CertificateRevocationRequest operations stall at PreviousCertificatesRevoked=False for 10+ minutes (3/8 runs, Jul 8-10, most frequent CI failure). #8563 fixed one instance of this class of bug (stale trust bundle cache returning requeueSoon=false), but three other return paths in each function have the same issue:

Line Condition Before After
:690, :1011 secretForSignerClass not found requeueSoon=false requeueSoon=true
:698, :1018 signer secret nil requeueSoon=false requeueSoon=true
:717, :1029 trust bundle ConfigMap nil requeueSoon=false requeueSoon=true

When any of these resources is transiently unavailable (being re-created, not yet propagated), the controller returned needsWork=true, requeueSoon=false — waiting for a watch event that might never come. With requeueSoon=true, it retries on the next synthetic requeue.

Frequency

3/8 runs in Jul 8-10 window. Most frequent issue in e2e-aws-ovn. One CRR completed in 2min while a parallel one in the same run stalled for 10min+ — consistent with a transient resource availability race.

Test plan

  • Unit test: "When trust bundle ConfigMap is transiently unavailable during revocation it should requeue"
  • go test ./control-plane-pki-operator/certificaterevocationcontroller/ — all pass
  • make lint — 0 issues
  • make verify — clean (except expected uncommitted files)

/cc @csrwng @CEWong

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Bug Fixes

  • Improved certificate revocation processing when required certificate or trust-bundle data is temporarily unavailable.

  • Reconciliation now automatically retries instead of stopping prematurely.

  • Tests

  • Added coverage for retry behavior when trust-bundle information is temporarily unavailable during certificate revocation.

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.

@jparrill

Copy link
Copy Markdown
Contributor Author

/test aws-e2e

@codecov

codecov Bot commented Jul 14, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 50.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 44.12%. Comparing base (7eb0da0) to head (1771608).
⚠️ Report is 12 commits behind head on main.

Files with missing lines Patch % Lines
...ationcontroller/certificaterevocationcontroller.go 50.00% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #8997      +/-   ##
==========================================
+ Coverage   44.11%   44.12%   +0.01%     
==========================================
  Files         772      772              
  Lines       96226    96226              
==========================================
+ Hits        42448    42463      +15     
+ Misses      50832    50822      -10     
+ Partials     2946     2941       -5     
Files with missing lines Coverage Δ
...ationcontroller/certificaterevocationcontroller.go 57.68% <50.00%> (+1.68%) ⬆️
Flag Coverage Δ
cmd-support 38.24% <ø> (ø)
cpo-hostedcontrolplane 46.16% <ø> (ø)
cpo-other 45.13% <ø> (ø)
hypershift-operator 54.09% <ø> (ø)
other 32.27% <50.00%> (+0.15%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🧹 Nitpick comments (1)
control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller_test.go (1)

2029-2042: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Cover the remaining changed requeue branches.

This test covers only the missing trust bundle during old-signer revocation. Verify that tests also cover missing signer data and missing trust bundles during new-signer propagation, plus a missing current signer during revocation; add focused subtests if they are not already covered.

As per coding guidelines, unit test any code changes and additions.

🤖 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
`@control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller_test.go`
around lines 2029 - 2042, Extend the certificate revocation controller tests
around processCertificateRevocationRequest to cover each remaining requeue
branch: missing signer data, missing trust bundle during new-signer propagation,
and missing current signer during revocation. Add focused subtests using the
existing revoked CRR, secret, controller, and expectation helpers, asserting no
error and requeue=true for each transiently unavailable dependency.

Source: Coding guidelines

🤖 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.

Nitpick comments:
In
`@control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller_test.go`:
- Around line 2029-2042: Extend the certificate revocation controller tests
around processCertificateRevocationRequest to cover each remaining requeue
branch: missing signer data, missing trust bundle during new-signer propagation,
and missing current signer during revocation. Add focused subtests using the
existing revoked CRR, secret, controller, and expectation helpers, asserting no
error and requeue=true for each transiently unavailable dependency.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: d2b5c30b-21e6-49dd-9aaf-78481e22e58b

📥 Commits

Reviewing files that changed from the base of the PR and between d241190 and 9fa0cbe.

📒 Files selected for processing (2)
  • control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller.go
  • control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller_test.go

@openshift-ci-robot

Copy link
Copy Markdown

@jparrill: This pull request references Jira Issue OCPBUGS-98461, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target version (5.0.0) matches configured target version for branch (5.0.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)
Details

In response to this:

Summary

  • Change requeueSoon from false to true in 6 return paths across ensureOldSignerCertificateRevoked and ensureNewSignerCertificatePropagated where a resource is transiently nil

Fixes

Root Cause

CertificateRevocationRequest operations stall at PreviousCertificatesRevoked=False for 10+ minutes (3/8 runs, Jul 8-10, most frequent CI failure). #8563 fixed one instance of this class of bug (stale trust bundle cache returning requeueSoon=false), but three other return paths in each function have the same issue:

Line Condition Before After
:690, :1011 secretForSignerClass not found requeueSoon=false requeueSoon=true
:698, :1018 signer secret nil requeueSoon=false requeueSoon=true
:717, :1029 trust bundle ConfigMap nil requeueSoon=false requeueSoon=true

When any of these resources is transiently unavailable (being re-created, not yet propagated), the controller returned needsWork=true, requeueSoon=false — waiting for a watch event that might never come. With requeueSoon=true, it retries on the next synthetic requeue.

Frequency

3/8 runs in Jul 8-10 window. Most frequent issue in e2e-aws-ovn. One CRR completed in 2min while a parallel one in the same run stalled for 10min+ — consistent with a transient resource availability race.

Test plan

  • Unit test: "When trust bundle ConfigMap is transiently unavailable during revocation it should requeue"
  • go test ./control-plane-pki-operator/certificaterevocationcontroller/ — all pass
  • make lint — 0 issues
  • make verify — clean (except expected uncommitted files)

/cc @csrwng

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Bug Fixes

  • Improved certificate revocation processing when required certificate or trust-bundle data is temporarily unavailable.

  • Reconciliation now automatically retries instead of stopping prematurely.

  • Tests

  • Added coverage for retry behavior when trust-bundle information is temporarily unavailable during certificate revocation.

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.

@ironcladlou

Copy link
Copy Markdown
Contributor

/lgtm

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Jul 14, 2026
@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aks
/test e2e-aws
/test e2e-aws-upgrade-hypershift-operator
/test e2e-azure-v2-self-managed
/test e2e-kubevirt-aws-ovn-reduced
/test e2e-v2-aws
/test e2e-v2-gke

@cwbotbot

cwbotbot commented Jul 14, 2026

Copy link
Copy Markdown

Test Results

e2e-aws

e2e-aks

@hypershift-jira-solve-ci

Copy link
Copy Markdown
Contributor

Both analyses are complete. Now I have the full picture for both jobs. Let me compile the final report.

Test Failure Analysis Complete

Job Information

Test Failure Analysis

Error

[e2e-aws] 12 of 457 tests failed — two patterns:

1. TestCreateCluster: "failed to apply object '/e2e-clusters-d845x': Internal error occurred:
   admission plugin 'ValidatingAdmissionPolicy' failed to complete validation in 13s"

2. TestAutoscaling, TestNodePool, TestCreateClusterProxy: "container control-plane-operator
   in pod control-plane-operator-... has too many restarts (5 > 0)"
   → CPO crash: "failed to get server groups: net/http: TLS handshake timeout"

[e2e-azure] 1 of 426 tests failed:

3. "container cluster-network-operator in pod cluster-network-operator-6c5c984c-9cfqv
   has too many restarts (1 > 0)"

Summary

Both job failures are caused by transient infrastructure/timing flakes during hosted cluster bring-up — none are related to the PR's code changes. The e2e-aws job hit two issues: (a) the management cluster API server was overloaded with 14+ concurrent hosted cluster creations, causing a 13-second ValidatingAdmissionPolicy timeout on namespace creation, and (b) control-plane-operator pods crashed during startup because the hosted cluster kube-apiserver was not yet serving TLS, then recovered after 5 restarts and ran normally. The e2e-azure job had a single cluster-network-operator container crash 3 seconds after first start during the cluster's Available=False phase, which recovered immediately on the second attempt. In all cases the EnsureNoCrashingPods test check flagged the historical restart counts even though the operators had fully recovered.

Root Cause

Neither job failure is caused by PR #8997. The PR only modifies certificaterevocationcontroller.go in the control-plane-pki-operator — all failing components (API server admission, CPO startup, CNO startup) are in entirely separate code paths.

e2e-aws: Two Distinct Failure Patterns

Pattern 1 — ValidatingAdmissionPolicy timeout (TestCreateCluster)
The management cluster's API server was under heavy load from 14+ hosted clusters being created simultaneously around 15:27–15:30 UTC. When TestCreateCluster attempted to create namespace e2e-clusters-d845x (the first object in hosted cluster setup), the ValidatingAdmissionPolicy admission plugin took >13 seconds to respond, exceeding its internal timeout. This is a transient resource contention issue.

Pattern 2 — control-plane-operator CrashLoopBackOff (TestAutoscaling, TestNodePool, TestCreateClusterProxy)
The CPO starts before the hosted cluster's kube-apiserver (KAS) is fully ready. During the bootstrap window, CPO attempts to call the KAS internal service endpoint (https://172.29.0.1:443/api) and hits:

  • net/http: TLS handshake timeout (KAS not yet serving TLS)
  • the server is currently unable to handle the request (KAS returning 503)

These crashes occurred at main.go:399 ("failed to setup event involvedObject.uid index") and main.go:411 ("unable to detect cluster capabilities") — both are startup initialization paths, not certificate revocation paths. The CPO recovered after ~2 minutes and 5 restarts once KAS became ready, but EnsureNoCrashingPods flagged the historical restartCount > 0.

e2e-azure: cluster-network-operator Startup Crash

Timeline:

  • 15:43:32 — CNO container started for the first time
  • 15:43:35 — CNO crashed within 3 seconds (no liveness probe; the process itself exited)
  • 15:43:35 — Second start succeeded; CNO ran normally thereafter
  • 15:45:14 — Hosted cluster reached Available=True (crash happened 2 minutes before availability)
  • 15:52:05EnsureNoCrashingPods test ran, found restartCount=1, and failed

The CNO crash occurred while the hosted cluster was in Available=False, VersionState=Partial state. A dependency (konnectivity connectivity, RBAC, or hosted cluster component) was not fully initialized during the 3-second window of the first start attempt.

Recommendations
  1. Re-trigger both jobs — These are transient infrastructure flakes unrelated to the PR. A re-run should pass.

  2. No code changes needed in PR OCPBUGS-98461: requeue CRR on transiently unavailable resources #8997 — The certificaterevocationcontroller.go changes (setting requeueSoon=true for transient nil resources) are safe and completely unrelated to all three failure patterns (admission policy timeout, CPO startup race, CNO startup race).

  3. Known flake patterns — Both the CPO startup race (TLS handshake timeout against not-yet-ready KAS) and the CNO startup crash during the Available=False window are known timing issues in the HyperShift bootstrap sequence. The EnsureNoCrashingPods check is intentionally strict but catches these transient startup restarts.

Evidence
Evidence Detail
e2e-aws failed step e2e-aws-hypershift-aws-run-e2e-nested — 12/457 tests failed, 422 passed, 23 skipped
e2e-aws Pattern 1 error admission plugin "ValidatingAdmissionPolicy" failed to complete validation in 13s on namespace e2e-clusters-d845x
e2e-aws Pattern 2 error CPO crash at main.go:399: failed to get server groups: Get "https://172.29.0.1:443/api": net/http: TLS handshake timeout
e2e-aws CPO restarts restartCount: 5, exitCode: 1; started 15:28:00, first crash 15:30:10, stabilized 15:31:44
e2e-aws concurrent load 14+ hosted clusters created simultaneously around 15:27–15:30 UTC
e2e-azure failed step e2e-azure-v2-self-managed-tests — 1/426 tests failed, 425 passed
e2e-azure error container cluster-network-operator in pod cluster-network-operator-6c5c984c-9cfqv has too many restarts (1 > 0)
e2e-azure CNO timeline First start 15:43:32, crashed 15:43:35 (3s), second start succeeded, cluster Available at 15:45:14
PR scope Only modifies certificaterevocationcontroller.go — sets requeueSoon=true in 6 nil-resource return paths
Component isolation Failing components (API admission, CPO main.go, CNO) have zero code overlap with the certificate revocation controller

@openshift-ci openshift-ci Bot removed the lgtm Indicates that a PR is ready to be merged. label Jul 15, 2026
Three return paths in ensureOldSignerCertificateRevoked and
ensureNewSignerCertificatePropagated returned requeueSoon=false when
a resource was transiently nil (signer secret, trust bundle
ConfigMap). Without a synthetic requeue, the controller waited for a
watch event that might never come — the same class of bug fixed in
openshift#8563 for the stale trust bundle cache case.

Change requeueSoon from false to true for these transient nil returns
so the controller retries instead of stalling.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Juan Manuel Parrilla Madrid <jparrill@redhat.com>

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🧹 Nitpick comments (1)
control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller.go (1)

686-699: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Requeuing forever on documented "should never happen" branches, with no logging. Both ensureNewSignerCertificatePropagated and ensureOldSignerCertificateRevoked have a secretForSignerClass !ok branch explicitly commented as unreachable (signer class is validated/immutable), yet both were switched from requeue=false to requeue=true as part of this change — the same blanket edit that correctly fixed the transient signer-secret/trust-bundle nil checks elsewhere. Unlike those transient cases, retrying an immutable-field mismatch can never converge, so if this branch is ever hit it will requeue indefinitely (with controller-runtime backoff) with zero error, event, or log to alert on the underlying misconfiguration.

  • control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller.go#L686-L699: add a warning log (or return an error) in the !ok branch of ensureNewSignerCertificatePropagated before requeuing, so a real occurrence isn't silently retried forever.
  • control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller.go#L1008-L1019: apply the same warning log (or error) to the equivalent !ok branch in ensureOldSignerCertificateRevoked.
🤖 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
`@control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller.go`
around lines 686 - 699, Handle the impossible signer-class branches in both
ensureNewSignerCertificatePropagated and ensureOldSignerCertificateRevoked by
emitting a warning log or returning an error before requeuing, so the mismatch
is visible and does not silently retry forever. Apply this change at
control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller.go
lines 686-699 and 1008-1019.
🤖 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.

Nitpick comments:
In
`@control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller.go`:
- Around line 686-699: Handle the impossible signer-class branches in both
ensureNewSignerCertificatePropagated and ensureOldSignerCertificateRevoked by
emitting a warning log or returning an error before requeuing, so the mismatch
is visible and does not silently retry forever. Apply this change at
control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller.go
lines 686-699 and 1008-1019.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: f7de3749-054e-432e-85d2-e534b00d8b32

📥 Commits

Reviewing files that changed from the base of the PR and between e7b0e5f and 1771608.

📒 Files selected for processing (2)
  • control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller.go
  • control-plane-pki-operator/certificaterevocationcontroller/certificaterevocationcontroller_test.go

@jparrill

Copy link
Copy Markdown
Contributor Author

/acknowledge-critical-fixes-only

@csrwng csrwng left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM — clean, minimal fix. All 6 return paths correctly flip requeueSoon from false to true for transiently nil resources. Requeue goes through AddRateLimited (exponential backoff starting at 5ms, capped at 1000s), so no risk of tight loops or API server pressure. The controller only reads secrets/ConfigMaps from the local informer cache at these points, so there's no contention with the control plane operator. Tests are well-structured and cover the exercisable paths.

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Jul 15, 2026
@openshift-ci

openshift-ci Bot commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: csrwng, jparrill

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

The pull request process is described 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

@csrwng csrwng added the acknowledge-critical-fixes-only Indicates if the issuer of the label is OK with the policy. label Jul 15, 2026
@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aks
/test e2e-aws
/test e2e-aws-upgrade-hypershift-operator
/test e2e-azure-v2-self-managed
/test e2e-kubevirt-aws-ovn-reduced
/test e2e-v2-aws
/test e2e-v2-gke

@jparrill

Copy link
Copy Markdown
Contributor Author

/retest-required

@jparrill

Copy link
Copy Markdown
Contributor Author

/verified by e2e

@openshift-ci-robot openshift-ci-robot added the verified Signifies that the PR passed pre-merge verification criteria label Jul 16, 2026
@openshift-ci-robot

Copy link
Copy Markdown

@jparrill: This PR has been marked as verified by e2e.

Details

In response to this:

/verified by e2e

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.

@jparrill

Copy link
Copy Markdown
Contributor Author

Failures are infrastructure-related, unrelated to this PR's CRR requeue fix:

  • e2e-aws: `CreateVpcEndpoint exceeded maximum number of attempts` (EC2 API throttling — tracked in OCPBUGS-98718 / OCPBUGS-98718: retry CreateVpcEndpoint on AWS throttle errors #9012) + `TestUpgradeControlPlane` infra failure. The `kubelet-config-verifier` DaemonSet passed correctly (3/3 ready).
  • e2e-azure-v2-self-managed: HC provisioning timeout — this job is failing 100% across all open PRs (Jul 15-16), not specific to this change.

@jparrill

Copy link
Copy Markdown
Contributor Author

/retest-required

Infra issue...

@openshift-ci

openshift-ci Bot commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

@jparrill: all tests passed!

Full PR test history. Your PR dashboard.

Details

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-sigs/prow repository. I understand the commands that are listed here.

@openshift-merge-bot
openshift-merge-bot Bot merged commit 13f579d into openshift:main Jul 16, 2026
39 checks passed
@openshift-ci-robot

Copy link
Copy Markdown

@jparrill: Jira Issue Verification Checks: Jira Issue OCPBUGS-98461
✔️ This pull request was pre-merge verified.
✔️ All associated pull requests have merged.
✔️ All associated, merged pull requests were pre-merge verified.

Jira Issue OCPBUGS-98461 has been moved to the MODIFIED state and will move to the VERIFIED state when the change is available in an accepted nightly payload. 🕓

Details

In response to this:

Summary

  • Change requeueSoon from false to true in 6 return paths across ensureOldSignerCertificateRevoked and ensureNewSignerCertificatePropagated where a resource is transiently nil

Fixes

Root Cause

CertificateRevocationRequest operations stall at PreviousCertificatesRevoked=False for 10+ minutes (3/8 runs, Jul 8-10, most frequent CI failure). #8563 fixed one instance of this class of bug (stale trust bundle cache returning requeueSoon=false), but three other return paths in each function have the same issue:

Line Condition Before After
:690, :1011 secretForSignerClass not found requeueSoon=false requeueSoon=true
:698, :1018 signer secret nil requeueSoon=false requeueSoon=true
:717, :1029 trust bundle ConfigMap nil requeueSoon=false requeueSoon=true

When any of these resources is transiently unavailable (being re-created, not yet propagated), the controller returned needsWork=true, requeueSoon=false — waiting for a watch event that might never come. With requeueSoon=true, it retries on the next synthetic requeue.

Frequency

3/8 runs in Jul 8-10 window. Most frequent issue in e2e-aws-ovn. One CRR completed in 2min while a parallel one in the same run stalled for 10min+ — consistent with a transient resource availability race.

Test plan

  • Unit test: "When trust bundle ConfigMap is transiently unavailable during revocation it should requeue"
  • go test ./control-plane-pki-operator/certificaterevocationcontroller/ — all pass
  • make lint — 0 issues
  • make verify — clean (except expected uncommitted files)

/cc @csrwng

🤖 Generated with Claude Code

Summary by CodeRabbit

Summary by CodeRabbit

  • Bug Fixes

  • Updated certificate revocation reconciliation to automatically retry when signer certificate secrets or aggregated trust-bundle data aren’t available yet.

  • Ensures reconciliation requeues (instead of prematurely completing) while prerequisites are still being propagated.

  • Tests

  • Added additional coverage for scenarios where the trust-bundle ConfigMap is temporarily missing, validating that the controller requeues without errors.

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-merge-robot

Copy link
Copy Markdown
Contributor

Fix included in release 5.0.0-0.nightly-2026-07-16-201519

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

Labels

acknowledge-critical-fixes-only Indicates if the issuer of the label is OK with the policy. approved Indicates a PR has been approved by an approver from all required OWNERS files. area/control-plane-pki-operator Indicates the PR includes changes for the control plane PKI operator - in an OCP release jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. verified Signifies that the PR passed pre-merge verification criteria

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants