Skip to content

OCPBUGS-88757: Align HCCO CatalogSource registryPoll interval with OCP defaults#8745

Open
shijadha wants to merge 1 commit into
openshift:mainfrom
shijadha:fix-catalogsource-poll-interval
Open

OCPBUGS-88757: Align HCCO CatalogSource registryPoll interval with OCP defaults#8745
shijadha wants to merge 1 commit into
openshift:mainfrom
shijadha:fix-catalogsource-poll-interval

Conversation

@shijadha

@shijadha shijadha commented Jun 16, 2026

Copy link
Copy Markdown

Summary

Updates the HCCO-managed CatalogSource registryPoll.interval from 10m to 240m to align with standard OCP 4.18+ defaults established by operator-marketplace.

Context

In standard OCP clusters (4.18+), the operator-marketplace component sets the default registryPoll interval to 240 minutes (4 hours) to address performance issues including unbounded etcd growth and high I/O on control plane nodes (see operator-marketplace PR #695 and OCPBUGS-69441).

In HyperShift/HCP hosted clusters, the Hosted Cluster Config Operator (HCCO) manages CatalogSources independently with its own reconciliation logic in catalogs.go, which still hardcodes the interval to 10 minutes. This creates inconsistency between standard OCP and HCP behavior.

Changes

  • Updated RawInterval from "10m" to "240m" in catalogs.go
  • Updated Interval duration from 10 * time.Minute to 240 * time.Minute

Benefits

  • Reduced control plane resource consumption: Less CPU/memory/network for catalog polling
  • Lower etcd churn: Fewer updates to CatalogSource status means less etcd I/O and storage growth
  • Better scalability: Management clusters hosting many HCP clusters see 24x reduction in aggregate polling load (4 catalogs × 6 polls/hour → 4 catalogs × 0.25 polls/hour per hosted cluster)
  • Consistency with standard OCP: HCP clusters behave the same as OCP 4.18+ clusters

Trade-offs

  • Catalog update discovery latency: When a new operator catalog image is pushed to the registry, discovery time increases from up to 10 minutes to up to 4 hours
  • Mitigation: Users can manually trigger refresh by deleting the CatalogSource pod or updating the spec.image field

Related Issues

  • OCPBUGS-88757 - HyperShift HCCO hardcodes CatalogSource registryPoll interval to 10m instead of 240m
  • OCPBUGS-88758 - Audit HyperShift HCCO for divergences from standard OCP component defaults
  • OCPBUGS-69441 - Original issue for standard OCP (fixed in operator-marketplace)

Testing

  • Code change is straightforward and low-risk (2 lines)
  • No functional behavior change, only timing adjustment
  • Follows established pattern from operator-marketplace

Summary by CodeRabbit

  • Chores
    • Increased the OLM CatalogSource registry polling interval from 10 minutes to 240 minutes (4 hours) to reduce how frequently catalogs are checked.
    • Updated repo ignore rules to exclude .mcp.json files.
  • Tests
    • Added CatalogSource reconciliation tests validating default spec settings (including the 240-minute polling interval), management vs. guest placement behavior, and preservation/merging of existing annotations.

@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-robot openshift-ci-robot added 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 Jun 16, 2026
@openshift-ci-robot

Copy link
Copy Markdown

@shijadha: This pull request references Jira Issue OCPBUGS-88757, 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

Updates the HCCO-managed CatalogSource registryPoll.interval from 10m to 240m to align with standard OCP 4.18+ defaults established by operator-marketplace.

Context

In standard OCP clusters (4.18+), the operator-marketplace component sets the default registryPoll interval to 240 minutes (4 hours) to address performance issues including unbounded etcd growth and high I/O on control plane nodes (see operator-marketplace PR #695 and OCPBUGS-69441).

In HyperShift/HCP hosted clusters, the Hosted Cluster Config Operator (HCCO) manages CatalogSources independently with its own reconciliation logic in catalogs.go, which still hardcodes the interval to 10 minutes. This creates inconsistency between standard OCP and HCP behavior.

Changes

  • Updated RawInterval from "10m" to "240m" in catalogs.go
  • Updated Interval duration from 10 * time.Minute to 240 * time.Minute

Benefits

  • Reduced control plane resource consumption: Less CPU/memory/network for catalog polling
  • Lower etcd churn: Fewer updates to CatalogSource status means less etcd I/O and storage growth
  • Better scalability: Management clusters hosting many HCP clusters see 24x reduction in aggregate polling load (4 catalogs × 6 polls/hour → 4 catalogs × 0.25 polls/hour per hosted cluster)
  • Consistency with standard OCP: HCP clusters behave the same as OCP 4.18+ clusters

Trade-offs

  • Catalog update discovery latency: When a new operator catalog image is pushed to the registry, discovery time increases from up to 10 minutes to up to 4 hours
  • Mitigation: Users can manually trigger refresh by deleting the CatalogSource pod or updating the spec.image field

Related Issues

  • OCPBUGS-88757 - HyperShift HCCO hardcodes CatalogSource registryPoll interval to 10m instead of 240m
  • OCPBUGS-88758 - Audit HyperShift HCCO for divergences from standard OCP component defaults
  • OCPBUGS-69441 - Original issue for standard OCP (fixed in operator-marketplace)

Testing

  • Code change is straightforward and low-risk (2 lines)
  • No functional behavior change, only timing adjustment
  • Follows established pattern from operator-marketplace

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 openshift-ci Bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. do-not-merge/needs-area labels Jun 16, 2026
@coderabbitai

coderabbitai Bot commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

The OLM catalog source reconciliation logic now sets the registry polling interval to 240 minutes instead of 10 minutes. The test file adds coverage for catalog source reconciliation helpers, including field defaults, placement-specific address/image handling, the updated polling interval, and annotation preservation. .mcp.json was added to .gitignore.

🚥 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 and concisely describes the main change: aligning HCCO CatalogSource registryPoll interval with OCP defaults.
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 The added test titles are static strings; no dynamic values, timestamps, UUIDs, or other unstable data appear in titles.
Test Structure And Quality ✅ Passed PASS: These are pure in-memory unit tests with isolated cases; no cluster resources, waits, or cleanup are involved, and they match repo t.Run/Gomega style.
Topology-Aware Scheduling Compatibility ✅ Passed Only the CatalogSource registryPoll interval changed; no new topology-sensitive selectors/affinity/PDBs were added, and the management annotation pre-existed.
Ipv6 And Disconnected Network Test Compatibility ✅ Passed Added tests are unit tests using t/Gomega only; they use placeholder image strings and contain no IPv4 assumptions or external connectivity.
No-Weak-Crypto ✅ Passed Touched files only change CatalogSource timing/tests; no MD5/SHA1/DES/RC4/3DES/Blowfish/ECB, custom crypto, or secret compares found.
Container-Privileges ✅ Passed The PR only changes CatalogSource polling and tests; the reconciler sets SecurityContextConfig to Restricted and no privileged/host* fields or allowPrivilegeEscalation=true were added.
No-Sensitive-Data-In-Logs ✅ Passed No logging was added in the touched files; the change only updates CatalogSource polling and tests.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

@openshift-ci openshift-ci Bot added area/control-plane-operator Indicates the PR includes changes for the control plane operator - in an OCP release needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jun 16, 2026
@openshift-ci

openshift-ci Bot commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

Hi @shijadha. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

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

Actionable comments posted: 2

🤖 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
`@control-plane-operator/hostedclusterconfigoperator/controllers/resources/olm/catalogs.go`:
- Around line 44-45: Add a unit test to verify the 240-minute polling interval
configuration change for the CatalogSource. Create a test function that
instantiates a CatalogSource, calls the function that modifies it (likely
ReconcileRedHatOperatorsCatalogSource based on the context), and then asserts
that both the RawInterval field equals "240m" and the Interval.Duration field
equals 240*time.Minute as shown in the provided example test structure. This
test should be placed in the appropriate test file for the catalogs.go module.
- Around line 44-45: The polling interval changes for the four default catalog
sources (certified, community, marketplace, red-hat-operators) in the
catalogs.go file lack accompanying unit tests. Add unit tests that verify the
RawInterval and Interval fields are correctly configured for each of the four
default catalog sources with the 240-minute polling interval. The tests should
validate that the interval values are properly set and match across both the
string representation and the metav1.Duration object for each catalog source.
🪄 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 YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 7d0e7fc3-d98e-44a5-ab91-4db377db2305

📥 Commits

Reviewing files that changed from the base of the PR and between 392fd5a and d83ffee.

📒 Files selected for processing (1)
  • control-plane-operator/hostedclusterconfigoperator/controllers/resources/olm/catalogs.go

@shijadha shijadha marked this pull request as ready for review June 17, 2026 16:02
@openshift-ci openshift-ci Bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 17, 2026
@openshift-ci openshift-ci Bot requested review from bryan-cox and sdminonne June 17, 2026 16:02
@oarribas

Copy link
Copy Markdown

/jira refresh

@openshift-ci-robot openshift-ci-robot added jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. and removed jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Jun 17, 2026
@openshift-ci-robot

Copy link
Copy Markdown

@oarribas: This pull request references Jira Issue OCPBUGS-88757, 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)
Details

In response to this:

/jira refresh

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.

@celebdor

Copy link
Copy Markdown
Collaborator

/jira refresh

@openshift-ci-robot

Copy link
Copy Markdown

@celebdor: This pull request references Jira Issue OCPBUGS-88757, 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:

/jira refresh

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.

@celebdor

Copy link
Copy Markdown
Collaborator

/ok-to-test

@openshift-ci openshift-ci Bot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jun 22, 2026
@muraee

muraee commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

/approve

@openshift-ci openshift-ci Bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 22, 2026
@codecov

codecov Bot commented Jun 22, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 43.57%. Comparing base (1f2811f) to head (d151050).
⚠️ Report is 30 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #8745      +/-   ##
==========================================
+ Coverage   43.53%   43.57%   +0.03%     
==========================================
  Files         771      771              
  Lines       95798    95798              
==========================================
+ Hits        41707    41741      +34     
+ Misses      51192    51158      -34     
  Partials     2899     2899              
Files with missing lines Coverage Δ
...nfigoperator/controllers/resources/olm/catalogs.go 100.00% <100.00%> (+100.00%) ⬆️
Flag Coverage Δ
cmd-support 37.22% <ø> (ø)
cpo-hostedcontrolplane 45.51% <ø> (ø)
cpo-other 45.36% <100.00%> (+0.26%) ⬆️
hypershift-operator 53.65% <ø> (ø)
other 32.08% <ø> (ø)

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.

@bryan-cox

Copy link
Copy Markdown
Member

Per OpenShift policies, coderabbit comments should be addressed before pinging human reviews. Can you please address/respond to the coderabbit comments?

@shijadha shijadha force-pushed the fix-catalogsource-poll-interval branch from d83ffee to d043889 Compare June 25, 2026 19:59

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

Actionable comments posted: 1

🤖 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
`@control-plane-operator/hostedclusterconfigoperator/controllers/resources/olm/catalogs_test.go`:
- Around line 52-56: The OLM catalog tests are dereferencing
RegistryPoll.Interval directly, which can panic if the field is unset; update
the assertions in the catalog test cases around the RegistryPoll checks to first
verify cs.Spec.UpdateStrategy.RegistryPoll.Interval is not nil before asserting
on .Duration. Keep the existing checks in the relevant test blocks in
catalogs_test.go, but add the nil guard wherever RegistryPoll.Interval is
accessed so failures are reported as assertions instead of panics.
🪄 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 YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: b63c1d13-0fb1-4daa-8173-5f3cd9fe07ab

📥 Commits

Reviewing files that changed from the base of the PR and between d83ffee and d043889.

📒 Files selected for processing (2)
  • control-plane-operator/hostedclusterconfigoperator/controllers/resources/olm/catalogs.go
  • control-plane-operator/hostedclusterconfigoperator/controllers/resources/olm/catalogs_test.go
🚧 Files skipped from review as they are similar to previous changes (1)
  • control-plane-operator/hostedclusterconfigoperator/controllers/resources/olm/catalogs.go

@shijadha shijadha force-pushed the fix-catalogsource-poll-interval branch from d043889 to 28076e4 Compare June 25, 2026 20:11
@oarribas

oarribas commented Jul 1, 2026

Copy link
Copy Markdown

Per OpenShift policies, coderabbit comments should be addressed before pinging human reviews. Can you please address/respond to the coderabbit comments?

@bryan-cox , if I'm not wrong, latest coderabbit comments are now addressed. Is it possible to review this PR for merging?

@bryan-cox bryan-cox left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

/lgtm

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

oarribas commented Jul 7, 2026

Copy link
Copy Markdown

Looks like the ok-to-test flag is missing. Who can add that flag to allow the workflow to continue?

@bryan-cox

Copy link
Copy Markdown
Member

/ok-to-test

@shijadha shijadha force-pushed the fix-catalogsource-poll-interval branch from 28076e4 to 016db67 Compare July 9, 2026 11:21
@openshift-ci openshift-ci Bot removed the lgtm Indicates that a PR is ready to be merged. label Jul 9, 2026
@bryan-cox

Copy link
Copy Markdown
Member

/ok-to-test

@shijadha shijadha force-pushed the fix-catalogsource-poll-interval branch 2 times, most recently from 322fea9 to 53086ff Compare July 9, 2026 12:26
@bryan-cox

Copy link
Copy Markdown
Member

/ok-to-test

Comment thread .gitignore

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This doesn't seem related to the PR

…terval with OCP defaults

Changes the OLM CatalogSource registry poll interval from 10m to 240m to match OpenShift
Container Platform default behavior.

Adds unit tests to verify the RegistryPoll configuration is correctly set and to prevent
regressions on the interval value.

Signed-off-by: Shital Jadhav <shijadha@redhat.com>
Commit-Message-Assisted-by: Claude (via Claude Code)
@shijadha shijadha force-pushed the fix-catalogsource-poll-interval branch from 53086ff to d151050 Compare July 9, 2026 14:32
@shijadha

shijadha commented Jul 9, 2026

Copy link
Copy Markdown
Author

@bryan-cox The .gitignore change has been removed. The PR now only contains the catalog poll interval changes (10m → 240m) and the associated unit tests. Thanks for catching that!

@oarribas

oarribas commented Jul 9, 2026

Copy link
Copy Markdown

New changes are detected. LGTM label has been removed.

Looks like the lgtm was also removed by the automation.

@bryan-cox

Copy link
Copy Markdown
Member

New changes are detected. LGTM label has been removed.

Looks like the lgtm was also removed by the automation.

@oarribas no it was removed because new code was pushed since lgtm was applied.

@bryan-cox bryan-cox left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Jul 9, 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

@openshift-ci

openshift-ci Bot commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bryan-cox, muraee, shijadha

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

@hypershift-jira-solve-ci

Copy link
Copy Markdown
Contributor

I now have all the evidence needed. The failure is a CI infrastructure issue on the build01 cluster. Here's the final report:

Test Failure Analysis Complete

Job Information

Test Failure Analysis

Error

Step e2e-aws-upgrade-hypershift-operator-hypershift-resolve-nodepool-releases failed:
pod pending for more than 1h0m0s: pod has not been scheduled in 1h0m0.000401411s

0/65 nodes are available: 1 node(s) didn't match pod anti-affinity rules,
12 node(s) didn't match Pod's node affinity/selector,
52 node(s) had untolerated taint(s).
preemption: 0/65 nodes are available: No preemption victims found for incoming pod.

Summary

This failure is a CI infrastructure scheduling issue on the build01 cluster — it is not related to the PR's code changes. The pre-phase step hypershift-resolve-nodepool-releases pod was created at 19:51:25 UTC but could never be scheduled onto any node in the CI cluster for 1 full hour, at which point ci-operator timed it out. The three preceding pre-phase steps (ipi-install-rbac, create-management-cluster, hypershift-install) all succeeded normally. The test phase never ran at all — the failure occurred entirely before any test code executed.

Root Cause

The pod e2e-aws-upgrade-hypershift-operator-hypershift-resolve-nodepool-releases could not be scheduled on any node in the build01 CI cluster for 1 hour, triggering the ci-operator pod-pending timeout. The scheduler events reveal why — across 65–71 nodes in the cluster, every single node was excluded:

  1. ~49–57 nodes had untolerated taints — The majority of nodes carried taints that the test pod did not tolerate. These are typically nodes reserved for other workloads or marked for specific purposes.

  2. 12 nodes didn't match Pod's node affinity/selector — The pod had a node affinity or nodeSelector that excluded these nodes (likely architecture or role constraints).

  3. 1–7 nodes were unschedulable — A small number of nodes were cordoned or in maintenance.

  4. 1 node didn't match pod anti-affinity rules — One eligible node was excluded because another pod with anti-affinity was already running there.

  5. Occasional "Insufficient memory" events — 8 scheduling events cited insufficient memory on the one remaining candidate node, indicating it was overcommitted.

The net result: zero nodes were ever schedulable for this pod during the entire 1-hour window. This is a CI cluster capacity/resource contention issue — the build01 cluster was saturated with workloads that consumed all available scheduling slots. The PR's code change (aligning HCCO CatalogSource registryPoll interval) had no effect on pod scheduling.

Recommendations
  1. Retry the job — This is a transient CI infrastructure issue. Re-triggering the job with /retest should succeed once cluster capacity frees up.

  2. No code changes needed — The PR (OCPBUGS-88757: Align HCCO CatalogSource registryPoll interval with OCP defaults #8745) modifies CatalogSource registryPoll interval configuration. This failure occurred in a CI pre-phase step before any test code from the PR ran. The failure is entirely due to CI cluster resource contention.

  3. If retries consistently fail — Escalate to the CI infrastructure team (TRT/DPTP) about build01 cluster capacity. The pattern of 49–57 tainted nodes out of 65–71 total suggests a significant portion of the cluster is reserved or unavailable for general workloads.

Evidence
Evidence Detail
Failed step hypershift-resolve-nodepool-releases (pre-phase, step 4 of 4)
Failure mode Pod pending timeout after 1h0m0s — never scheduled
Job state reason pod_pending
Scheduler events 103 events, all showing 0 schedulable nodes
Node breakdown (typical) 65 nodes: 52 tainted, 12 affinity mismatch, 1 anti-affinity, 1 unschedulable
Insufficient memory 8 events citing memory on candidate node
Succeeded pre-steps ipi-install-rbac (35m47s), create-management-cluster (40m6s), hypershift-install (1m51s)
Pod created 2026-07-09T19:51:25Z
Pod timed out 2026-07-09T20:51:25Z
CI cluster build01
PR relevance None — failure occurred before any PR code executed

@shijadha

Copy link
Copy Markdown
Author

/retest

@bryan-cox

Copy link
Copy Markdown
Member

/ok-to-test

@openshift-ci

openshift-ci Bot commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

@shijadha: 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.

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

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. area/control-plane-operator Indicates the PR includes changes for the control plane 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. ok-to-test Indicates a non-member PR verified by an org member that is safe to test.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants